Hi.
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Just out of curiosity, could you try the appended cumulative patch
> and report .clock_warps, .clock_overflows and .clock_underflows as
> you did.
With those patches, CONFIG_NO_HZ works just fine.
>> Co
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> FYI, I'm currently trying to track down where rq->clock started to
> overflow with nohz=off, and it seems to be before 2.6.23, so my patches
> are not at fault ;-) Or maybe I am dreaming and it was always
> overflowing. Investigating ...
And the wi
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok. I have applied all but this one
Hmm, I couldn't find them in mingo/linux-2.6-sched-devel.git.
> i think it's much simpler to do what i have below. Could you try it on
> your box? Or if it is using ACPI idle - in that case the callbacks
> should alre
On Fri, 2008-01-11 at 10:34 +0100, Ingo Molnar wrote:
> * David Dillow <[EMAIL PROTECTED]> wrote:
>
> > Ingo, Thomas added as I think this is related to
> > sched.c:__update_rq_clock()'s checking for forward time warps.
>
> yep, we've got some fixes in this area. Do blktrace timestamps work fin
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> David Dillow <[EMAIL PROTECTED]> wrote:
>
> > Patched kernel, nohz=off:
> > .clock_underflows : 213887
>
> A little bit of warning about these patches, they are WIP, that's why
> I did not send them earlier. It regress nohz=off.
David Dillow <[EMAIL PROTECTED]> wrote:
> Patched kernel, nohz=off:
> .clock_underflows : 213887
A little bit of warning about these patches, they are WIP, that's why I
did not send them earlier. It regress nohz=off.
A bit of context: these patches aim at making sure cpu_clock() o
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > they are from the scheduler git tree (except the first debug patch),
> > > but queued up for v2.6.25 at the moment.
> >
> > So this means that blktrace will be broken with CONFIG_NO_HZ for
> > 2.6.24? T
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > With those patches, CONFIG_NO_HZ works just fine.
>
> could you please try the two patches below, do they fix the problem as
> well? They got a ton of testing in x86.git in the past ~2 months and
> we could perhaps still push them into v2.6.24.
plu
* David Dillow <[EMAIL PROTECTED]> wrote:
> > Just out of curiosity, could you try the appended cumulative patch
> > and report .clock_warps, .clock_overflows and .clock_underflows as
> > you did.
>
> With those patches, CONFIG_NO_HZ works just fine.
could you please try the two patches below
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > they are from the scheduler git tree (except the first debug patch),
> > but queued up for v2.6.25 at the moment.
>
> So this means that blktrace will be broken with CONFIG_NO_HZ for
> 2.6.24? That's clearly a regression.
64-bit CONFIG_NO_HZ is a ne
* David Dillow <[EMAIL PROTECTED]> wrote:
> Ingo, Thomas added as I think this is related to
> sched.c:__update_rq_clock()'s checking for forward time warps.
yep, we've got some fixes in this area. Do blktrace timestamps work fine
in v2.6.23, with NOHZ?
Ingo
--
To unsubscribe from thi
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Thanks for reporting this. Guillaume, did you write this patch? We
> > > need to get it into 2.6.24-rc7 asap. Let me know if I should take
> > > care of that, or if it's already queued up elsewhere.
> >
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> Just out of curiosity, could you try the appended cumulative patch
> >>> and report .clock_warps, .clock_overflows and .clock_underflows as
> >>> you did.
> >> With those patches, CONFIG_NO_HZ works just fine.
>
> Could these patches also he
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Thanks for reporting this. Guillaume, did you write this patch? We
> > need to get it into 2.6.24-rc7 asap. Let me know if I should take
> > care of that, or if it's already queued up elsewhere.
>
> they are from the scheduler git tree (except the f
Hi.
Jens Axboe wrote:
> On Thu, Jan 10 2008, David Dillow wrote:
>> On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote:
>>> David Dillow <[EMAIL PROTECTED]> wrote:
>>>
At the moment, I'm not sure how to track this farther, or how to fix it
properly. Any advice would be apprecia
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > Thanks for reporting this. Guillaume, did you write this patch? We
> > need to get it into 2.6.24-rc7 asap. Let me know if I should take care
> > of that, or if it's already queued up elsewhere.
>
> they
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> Thanks for reporting this. Guillaume, did you write this patch? We
> need to get it into 2.6.24-rc7 asap. Let me know if I should take care
> of that, or if it's already queued up elsewhere.
they are from the scheduler git tree (except the first debug
On Thu, Jan 10 2008, David Dillow wrote:
>
> On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote:
> > David Dillow <[EMAIL PROTECTED]> wrote:
> >
> > > At the moment, I'm not sure how to track this farther, or how to fix it
> > > properly. Any advice would be appreciated.
> >
> > Just o
On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote:
> David Dillow <[EMAIL PROTECTED]> wrote:
>
> > At the moment, I'm not sure how to track this farther, or how to fix it
> > properly. Any advice would be appreciated.
>
> Just out of curiosity, could you try the appended cumulative pa
David Dillow <[EMAIL PROTECTED]> wrote:
> At the moment, I'm not sure how to track this farther, or how to fix it
> properly. Any advice would be appreciated.
Just out of curiosity, could you try the appended cumulative patch and
report .clock_warps, .clock_overflows and .clock_underflows as you
Ingo, Thomas added as I think this is related to
sched.c:__update_rq_clock()'s checking for forward time warps.
On Wed, 2008-01-09 at 17:48 -0500, David Dillow wrote:
> While trying to gain some insight into a disk issue, I found that
> blktrace/blkparse was giving me bogus traces -- I was seeing
While trying to gain some insight into a disk issue, I found that
blktrace/blkparse was giving me bogus traces -- I was seeing requests
complete before they were even dispatched or queued even! I had thought
that maybe this was an issue with SMP on the box, but when running with
'maxcpus=1', it tol
22 matches
Mail list logo
