On Mon, Jan 14 2008, Christoph Hellwig wrote:
>
> Folks, this is getting a little silly.
It is
> Even if CONFIG_NO_HZ is new this is a an important regression, and
> yes we should avoid regressions wherever we can, and for such a quite
> important feature we should fix it. On the other hand blk
Folks, this is getting a little silly.
Even if CONFIG_NO_HZ is new this is a an important regression, and
yes we should avoid regressions wherever we can, and for such a quite
important feature we should fix it. On the other hand blktrace is using
the wrong interface, and it has been told multip
On Mon, Jan 14 2008, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > because a perfectly working system is:
> >
> > "a user's .config that worked before should work with the new kernel
> > too"
> >
> > not:
> >
> > "a user's .config that worked before should work now
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> because a perfectly working system is:
>
> "a user's .config that worked before should work with the new kernel
> too"
>
> not:
>
> "a user's .config that worked before should work now too, with random
> new kernel features enabled as well."
>
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > - Fact: feature CONFIG_CPU_IDLE=y did not exist in 64-bit x86 in v2.6.23.
> > It has known bugs but they are not flagged 'regressions' (because the
> > feature did not exist before and the option is default-disabled) hence
> > the feature can st
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * David Dillow <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2008-01-11 at 11:29 +0100, Ingo Molnar wrote:
> > > (David, could you try the patch further below - does it fix bkltrace
> > > timestamps too?)
> >
> > Jens already got back to you, but I can con
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > > If blktrace worked in 2.6.23 and it doesn't in 2.6.24 because of
> > > > some option that isn't immediately apparent, then it's a
> > > > regression. Period.
> > >
> > > not completely correct. CONFIG
* David Dillow <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-01-11 at 11:29 +0100, Ingo Molnar wrote:
> > (David, could you try the patch further below - does it fix bkltrace
> > timestamps too?)
>
> Jens already got back to you, but I can confirm it works here as well.
great, thanks for testing i
On Fri, 2008-01-11 at 11:29 +0100, Ingo Molnar wrote:
> (David, could you try the patch further below - does it fix bkltrace
> timestamps too?)
Jens already got back to you, but I can confirm it works here as well.
--
Dave Dillow
National Center for Computational Science
Oak Ridge National Labo
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > If blktrace worked in 2.6.23 and it doesn't in 2.6.24 because of
> > > some option that isn't immediately apparent, then it's a
> > > regression. Period.
> >
> > not completely correct. CONFIG_NO_HZ is a default-disabled option
> > that became new
On Fri, Jan 11 2008, Jens Axboe wrote:
> > ktime_get() should have been used instead, which is a proper GTOD
> > clocksource. The patch below implements this.
>
> Will give it a whirl, it looks promising indeed and gets rid of the ugly
> cpu sync stuff. What is the cost of ktime_get() compared to
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> (David, could you try the patch further below - does it fix bkltrace
> timestamps too?)
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jan 11 2008, Ingo Molnar wrote:
> > >
> > > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> > >
> > > > > the
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> > Correction: it was not a high res time source, it was "the
> > scheduler's per-cpu, non-exported, non-coherent,
> > warps-and-jumps-like-hell high-res timesource that was intentionally
> > called the _sched_ clock" ;-)
>
> I think the warts
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Correction: it was not a high res time source, it was "the scheduler's
> per-cpu, non-exported, non-coherent, warps-and-jumps-like-hell high-res
> timesource that was intentionally called the _sched_ clock" ;-)
I think the warts of cpu_clock() are fixabl
(David, could you try the patch further below - does it fix bkltrace
timestamps too?)
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11 2008, Ingo Molnar wrote:
> >
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > > they are from the scheduler git tree (except the first debug patc
15 matches
Mail list logo