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
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
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."
>
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 too, with random
* 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.
the latter
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
* 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
* 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 stay. Some
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
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.
* 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
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
* 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
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
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:
> > >
> > > > >
* 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
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
(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
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 fixable,
* 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 of
(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 patch),
but
* 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 newly available on
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
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:
they are from the scheduler
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 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
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_NO_HZ is a
* 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 it. (i'm
29 matches
Mail list logo
