Hi Ingo,
Can I talk you into dropping these patches of mine from sched-devel
(or not send them to Linus):
da0f9440cdcb1edd5424de91f326de83de3fe5f9 sched: make sure jiffies is
up to date before calling __update_rq_clock()
6eb300ad38fef6db4efe177067a65aaa771596da sched: fix rq->clock
overflows detection with CONFIG_NO_HZ
They are not of good enough quality, and I'm working on a better approach.
Thanks.
--
Guillaume
* Guillaume Chazarain <[email protected]> wrote:
> Hi Ingo,
>
> Can I talk you into dropping these patches of mine from sched-devel
> (or not send them to Linus):
>
> da0f9440cdcb1edd5424de91f326de83de3fe5f9 sched: make sure jiffies is
> up to date before calling __update_rq_clock()
> 6eb300ad38fef6db4efe177067a65aaa771596da sched: fix rq->clock
> overflows detection with CONFIG_NO_HZ
>
> They are not of good enough quality, and I'm working on a better
> approach.
sure, done.
what method are you using of determining quality? Could you perhaps try
to automate it? (even better would be some self-test within the kernel
that detects badness)
Ingo
On Jan 25, 2008 5:58 PM, Ingo Molnar <[email protected]> wrote:
> sure, done.
Thanks.
> what method are you using of determining quality?
I was talking about code quality: adding a dependency on jiffies does
not seems like a good idea. But also, about the clock quality, I was
focusing on getting rid of underflows and overflows so relaxed the
checks. But I realized all these underflows are definitely needed. I
mean, the conversion from TSC to sched_clock always rounds to lower,
so overtime it lags a bit.
> Could you perhaps try
> to automate it? (even better would be some self-test within the kernel
> that detects badness)
I find the overflow/underflow/warps checks you added in the first
place to be sufficent. Not sure we want to add more tests to
differentiate between normal and abnormal drifts.
Thanks for your prompt reply.
--
Guillaume