On Mon, 2007-01-29 at 13:31 -0800, john stultz wrote:
> Should I just revive the old 2.6.20-rc4-mm1 patches against your current
> tree and re-submit? Or should the HRT bits get settled first?
Thomas just pointed out that I had missed that the bits are back in
-mm2.
Sorry for the noise.
-john
-
On Sat, 2007-01-27 at 18:17 -0800, Andrew Morton wrote:
> On Tue, 23 Jan 2007 22:00:55 -
> Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > This is a full replacement queue for the high resolution timer / dynamic
> > ticks implemementation in -mm.
>
> The Vaio broke again. Seems to hang per
On Tue, 23 Jan 2007 22:00:55 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> This is a full replacement queue for the high resolution timer / dynamic
> ticks implemementation in -mm.
The Vaio broke again. Seems to hang permanently the first time it tries to
sleep. The cursor doesn't flash.
On Thu, 2007-01-25 at 07:32 +0100, Ingo Molnar wrote:
> * john stultz <[EMAIL PROTECTED]> wrote:
>
> > Although, to be fair, I do know that Daniel has future sched_clock
> > related patches that need his cleanups [...]
>
> btw., i dont find those sched_clock() changes really acceptable in their
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > Thomas' changes are more obviously purpose driven, and Daniel's
> > appear more like just cleanups. So given that, if it were me, I'd
> > put Thomas changes in first, and re-diff Daniel's non-redundant
> > changes on top.
>
> Seems backwards , cl
* john stultz <[EMAIL PROTECTED]> wrote:
> Although, to be fair, I do know that Daniel has future sched_clock
> related patches that need his cleanups [...]
btw., i dont find those sched_clock() changes really acceptable in their
present form, and i've pointed out my reasons for that in the pa
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> Only in so much as the high res changes parallel my own. That includes
> from my set the update_callback removal and the rating sorted list.
> thats about where the similarity stops, even those changes don't
> appear to have the breath of mine.
bec
On Wed, 2007-01-24 at 13:23 -0800, john stultz wrote:
> Well, I suggested the kernel/time/timekeeping.c change go in last cycle,
> when you pushed your other cleanups, because that sort of large,
> move-tons-of-code patch sucks to keep out of the tree for long as it
> would surely collide with som
On Wed, 2007-01-24 at 12:51 -0800, Daniel Walker wrote:
> On Wed, 2007-01-24 at 11:57 -0800, john stultz wrote:
> > Thomas' changes are more obviously purpose driven, and Daniel's appear
> > more like just cleanups. So given that, if it were me, I'd put Thomas
> > changes in first, and re-diff Dani
On Wed, 2007-01-24 at 11:57 -0800, john stultz wrote:
> On Wed, 2007-01-24 at 01:30 -0800, Daniel Walker wrote:
> >
> > My patch set has been stable for months, and reviewed and tested by
> > John and I constantly (With you and Thomas on the CC list each
> > release).. It's a completely safe bet,
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> I think his approach was wrong that's why I'm resistant to his
> implementation .. [...]
how can you still say this while you showed clear misunderstanding of
what Thomas did and why? Why should i care about you being 'resistant'
to anything under
On Wed, 2007-01-24 at 20:38 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > you are also misunderstanding the change. While the TSC is the only
> > > unstable clocksource right now, the previous code tied the TSC to
> > > the >pm-timer< clocksource. This change mak
On Wed, 2007-01-24 at 01:30 -0800, Daniel Walker wrote:
>
> My patch set has been stable for months, and reviewed and tested by
> John and I constantly (With you and Thomas on the CC list each
> release).. It's a completely safe bet, IMO .
Oh, I really wanted to stay out of this, but just a smal
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > you are also misunderstanding the change. While the TSC is the only
> > unstable clocksource right now, the previous code tied the TSC to
> > the >pm-timer< clocksource. This change makes it generic, hence the
> > TSC can be verified by a hpet-onl
On Wed, 2007-01-24 at 17:00 +0100, Ingo Molnar wrote:
> you are also misunderstand the change. While the TSC is the only
> unstable clocksource right now, the previous code tied the TSC to the
> >pm-timer< clocksource. This change makes it generic, hence the TSC can
> be verified by a hpet-only sy
On Wed, 2007-01-24 at 12:13 +0100, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 02:23 -0800, Daniel Walker wrote:
> > > the 10th major iteration to his codebase. If you have cleanups to his
> > > code then please work with Thomas to get your changes into his tree.
> >
> > My code is for clockso
On Wed, 2007-01-24 at 02:23 -0800, Daniel Walker wrote:
> > the 10th major iteration to his codebase. If you have cleanups to his
> > code then please work with Thomas to get your changes into his tree.
>
> My code is for clocksouces/timekeeping which has been unrelated to HRT
> up until recently
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > > > If stability is a question, -rt10 does currently compile for
> > > > > my test config, due to this new HRT introduction. [...]
[...]
NOTE: the build problem you have is -rt specific. In any case it is not
due to this new HRT introduction but
On Wed, 2007-01-24 at 11:29 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > No, the test config I was talking about is SMP i386 (which is what I
> > usually use). [...]
>
> then please send me the .config.
Sure.
Daniel
#
# Automatically generated make config: don't
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> No, the test config I was talking about is SMP i386 (which is what I
> usually use). [...]
then please send me the .config.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
On Wed, 2007-01-24 at 10:51 +0100, Ingo Molnar wrote:
> please read what i wrote: in the first section above i am talking about
> Thomas' -hrt tree and its track record. Thomas' tree is more than a year
> old and has an excellent track record. In the last sentence i was
> talking about this lat
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > i disagree. Thomas' tree has been tested in -rt for some time
> > already, and he's the author of this code so as far as i'm concerned
> > he calls the shots of what to do and in what order to do. He did the
> > overwhelming majority of regression
On Wed, 2007-01-24 at 08:07 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > To lessen Andrews burden it would be wise to integrate the two trees
> > prior to anything going into -mm .. [...]
>
> i disagree. Thomas' tree has been tested in -rt for some time already,
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> To lessen Andrews burden it would be wise to integrate the two trees
> prior to anything going into -mm .. [...]
i disagree. Thomas' tree has been tested in -rt for some time already,
and he's the author of this code so as far as i'm concerned he ca
On Tue, 2007-01-23 at 18:23 -0800, Andrew Morton wrote:
> > There appears to be some fairly clear duplication between my clocksource
> > tree and this release of high resolution timers. Not to mention that we
> > both submitted our tree's to Andrew within days .
> >
> > To lessen Andrews burden
On Tue, 23 Jan 2007 18:16:31 -0800
Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-01-23 at 22:00 +, Thomas Gleixner wrote:
> > - Provide a generic way to verify clocksources. TSC needs
> >verification due to broken hardware and BIOS implementations. The
> >previous attempt to
On Tue, 2007-01-23 at 22:00 +, Thomas Gleixner wrote:
> - Provide a generic way to verify clocksources. TSC needs
>verification due to broken hardware and BIOS implementations. The
>previous attempt to allow TSC usage for high resolution and/or
>dynamic ticks only in combination wi
This is a full replacement queue for the high resolution timer / dynamic
ticks implemementation in -mm.
This version includes the following improvements:
- Seperate clockevents management of devices and users
- Provide a generic tick managament infrastructure, which makes use
of the clock
28 matches
Mail list logo
