On Fri, 2007-07-13 at 19:23 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 13 Jul 2007, Mike Galbraith wrote:
>
> > > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > > attempt to scale that down a little...
> >
> > See prio_to_weight[], prio_to_wmult[] and
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
> > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > attempt to scale that down a little...
>
> See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
> Perhaps more can be done, but "without any
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
The new scheduler does _a_lot_ of heavy 64 bit calculations without any
attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
Perhaps more can be done, but without any attempt...
On Fri, 2007-07-13 at 19:23 +0200, Roman Zippel wrote:
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
The new scheduler does _a_lot_ of heavy 64 bit calculations without any
attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and
On Fri, 2007-07-13 at 04:23 +0200, Roman Zippel wrote:
> Hi,
Hi,
> The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
Perhaps more can be done, but "without
On Fri, 13 Jul 2007 04:23:43 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On Wed, 11 Jul 2007, Linus Torvalds wrote:
>
> > Sure, bugs happen, but code that everybody runs the same generally doesn't
> > break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
Hi,
On Wed, 11 Jul 2007, Linus Torvalds wrote:
> Sure, bugs happen, but code that everybody runs the same generally doesn't
> break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
> are "easy".
A little more advance warning wouldn't have hurt though.
The new scheduler does
On Thu, Jul 12, 2007 at 12:50:19AM +0200, Thomas Gleixner wrote:
> Linus,
>
> On Wed, 2007-07-11 at 15:20 -0700, Linus Torvalds wrote:
> > For example, we can make sure that the code in question that actually
> > touches the hardware stays exactly the same, and then just move the
> > interfaces
On Thu, Jul 12, 2007 at 12:33:43PM -0700, Christoph Lameter wrote:
> On Wed, 11 Jul 2007, Andi Kleen wrote:
>
> > These all need re-review:
> >
> > > i386-add-support-for-picopower-irq-router.patch
> > > make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
> > >
On Wed, 11 Jul 2007, Andi Kleen wrote:
> These all need re-review:
>
> > i386-add-support-for-picopower-irq-router.patch
> > make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
> > arch-i386-kernel-i8253c-should-include-asm-timerh.patch
> >
* Linus Torvalds "Wed, 11 Jul 2007 15:09:28 -0700 (PDT)"
>
> On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
>>
>> I'm going to change topic big time because your sentence above
>> perfectly applies to the O(1) scheduler too.
>
> I disagree to a large degree.
>
> We almost never have problems with
* Linus Torvalds Wed, 11 Jul 2007 15:09:28 -0700 (PDT)
On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
I'm going to change topic big time because your sentence above
perfectly applies to the O(1) scheduler too.
I disagree to a large degree.
We almost never have problems with code you can
On Wed, 11 Jul 2007, Andi Kleen wrote:
These all need re-review:
i386-add-support-for-picopower-irq-router.patch
make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
arch-i386-kernel-i8253c-should-include-asm-timerh.patch
On Thu, Jul 12, 2007 at 12:33:43PM -0700, Christoph Lameter wrote:
On Wed, 11 Jul 2007, Andi Kleen wrote:
These all need re-review:
i386-add-support-for-picopower-irq-router.patch
make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
On Thu, Jul 12, 2007 at 12:50:19AM +0200, Thomas Gleixner wrote:
Linus,
On Wed, 2007-07-11 at 15:20 -0700, Linus Torvalds wrote:
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
interfaces around -
Hi,
On Wed, 11 Jul 2007, Linus Torvalds wrote:
Sure, bugs happen, but code that everybody runs the same generally doesn't
break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
are easy.
A little more advance warning wouldn't have hurt though.
The new scheduler does
On Fri, 2007-07-13 at 04:23 +0200, Roman Zippel wrote:
Hi,
Hi,
The new scheduler does _a_lot_ of heavy 64 bit calculations without any
attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
Perhaps more can be done, but without any
On Fri, 13 Jul 2007 04:23:43 +0200 (CEST) Roman Zippel [EMAIL PROTECTED]
wrote:
Hi,
On Wed, 11 Jul 2007, Linus Torvalds wrote:
Sure, bugs happen, but code that everybody runs the same generally doesn't
break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
are
On Wed, 2007-07-11 at 15:58 -0700, Linus Torvalds wrote:
>
> On Wed, 11 Jul 2007, Chris Wright wrote:
> >
> > That's not quite right. Leaving the code unchanged caused breakage
> > already. The PIT is damn stupid and can be sensitive to how quickly it's
> > programmed. So code that
On Thu, Jul 12, 2007 at 02:18:07AM +0200, Ingo Molnar wrote:
> > > i dont think "clean, modern x86 code" will ever happen - x86_64 has
> > > and is going to have the exact same type of crap. And i'll say a
> > > weird thing
> >
> > Yes, but it will be new crap, but no old crap anymore.
> >
> >
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i dont think "clean, modern x86 code" will ever happen - x86_64 has
> > and is going to have the exact same type of crap. And i'll say a
> > weird thing
>
> Yes, but it will be new crap, but no old crap anymore.
>
> If you always pile the new crap
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> The equivalent to the powerpc way would be essentially to report i386
> into the x86-64 code base and leave the really old hardware only
> in arch/i386. I've considered doing it, but it would be an awful
> lot of work and to tempt distributions to actually
> i dont think "clean, modern x86 code" will ever happen - x86_64 has and
> is going to have the exact same type of crap. And i'll say a weird thing
Yes, but it will be new crap, but no old crap anymore.
If you always pile the new crap on the old crap at some point
the whole thing might fall
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The same is true of a lot of the APIC timer code. Sure, that patch
> > has the actual conversion in it, and you don't have the
> > cross-architecture issues, but more than 50% of the patch seems to
> > be just cleanup that is independent of the
Andi,
On Thu, 2007-07-12 at 01:36 +0200, Andi Kleen wrote:
> > The same is true of a lot of the APIC timer code. Sure, that patch has the
> > actual conversion in it, and you don't have the cross-architecture issues,
> > but more than 50% of the patch seems to be just cleanup that is
> >
On Thu, 12 Jul 2007, Ingo Molnar wrote:
>
> We also integrated _all_ feedback we got, and we had the capacity and
> capability to fix whatever other feedback comes back - it just never
> came ... until today.
One thing I'll happily talk about is that while 2.6.21 was painful, you
and Thomas
> The same is true of a lot of the APIC timer code. Sure, that patch has the
> actual conversion in it, and you don't have the cross-architecture issues,
> but more than 50% of the patch seems to be just cleanup that is
> independent of the actual switch-over, no?
I don't think it's that much
Linus,
On Wed, 2007-07-11 at 16:07 -0700, Linus Torvalds wrote:
> Why not just fix up the HPET code so that it can be shared *first*.
> Without the other conversion? Really - What's so wrong with the hpet.c
> changes in the *absense* of conversion to clockevents? Those changes seem
> to be
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That was *exactly* the same thing you talked about when I refused to
> take the original timer changes into 2.6.20. You were talking about
> how lots of people had worked really hard, and how it was really
> tested.
yes - i was (way too!) upset
On Wed, 11 Jul 2007 23:39:19 +0200 Thomas Gleixner wrote:
> Randy,
>
> On Wed, 2007-07-11 at 14:02 -0700, Randy Dunlap wrote:
> > I certainly haven't. I can barely keep up with reading about 1/2
> > of lkml emails. And in my non-scientific method, I think that we
> > are suffering from both
On Thu, 12 Jul 2007, Thomas Gleixner wrote:
>
> The HPET change, which is the larger part of the conversion set simply
> because we now share the code with i386, might be split out by disabling
> HPET in the first step, doing the PIT / APIC conversion and then the
> HPET one in a separate step.
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> The HPET change, which is the larger part of the conversion set simply
> because we now share the code with i386, might be split out by disabling
> HPET in the first step, doing the PIT / APIC conversion and then the
> HPET one in a separate step.
On Wed, 11 Jul 2007, Chris Wright wrote:
>
> That's not quite right. Leaving the code unchanged caused breakage
> already. The PIT is damn stupid and can be sensitive to how quickly it's
> programmed. So code that enable/disable didn't change, but frequency
> with which it is called did and
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> For example, we can make sure that the code in question that actually
> touches the hardware stays exactly the same, and then just move the
> interfaces around - and basically guarantee that _zero_ hardware-specific
> issues pop up when you switch
Linus,
On Wed, 2007-07-11 at 15:20 -0700, Linus Torvalds wrote:
> For example, we can make sure that the code in question that actually
> touches the hardware stays exactly the same, and then just move the
> interfaces around - and basically guarantee that _zero_ hardware-specific
> issues pop
On Wed, 11 Jul 2007, [EMAIL PROTECTED] wrote:
>
> D'Oh! :) Yeah, the -rc4 version I'm
> looking at is like a dozen 1-3K patches setting up and cleaning up, and then
> one monster 65K patch doing the clockevents conversion, then another 6 or 8
> small ones.
>
> Yeah, that one big patch
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Andrew - how do you feel about keeping this in the -mm tree until Linus,
> Andi, Ingo, and Thomas get on the same page (which may be around the 2.6.24
> merge window, by my guesstimate)?
Well, that's supposed to be Andi's tree and aggregated by
On Thu, 12 Jul 2007, Thomas Gleixner wrote:
>
> Can you please shed some light on me, how exactly you switch an
> architecture gradually to clock events.
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
On Wed, Jul 11, 2007 at 11:46:41PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Wed, 2007-07-11 at 23:16 +0200, Andi Kleen wrote:
> > > What contribution do we have from you instead? A week before the .23
> >
> > I told him my objections privately earlier. Basically i would
> > like to see an
On Wed, 11 Jul 2007, [EMAIL PROTECTED] wrote:
>
> Odd, I looked at the patchset fairly closely a number of times, as I was
> hand-retrofitting the -rc[1-4] versions onto -rc[1-4]-mm kernels, and it
> looked
> to *me* like it was a nice set of 20 or so step-by-step changes (bisectable
> and
On Wed, 11 Jul 2007 14:54:12 PDT, Chris Wright said:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
> > (Note - I'm just a usually-confused crash test dummy here...)
> >
> > > Well I spent a lot of time making the x86-64 timing code work
On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
>
> I'm going to change topic big time because your sentence above
> perfectly applies to the O(1) scheduler too.
I disagree to a large degree.
We almost never have problems with code you can "think about".
Sure, bugs happen, but code that
Linus,
On Wed, 2007-07-11 at 14:42 -0700, Linus Torvalds wrote:
> Here's a big clue: it doesn't matter one _whit_ how much face-slapping you
> get, or how much effort some programmers have put into the code. It's
> untested. And no, we are *not* going to do another "rip everything out,
> and
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
> (Note - I'm just a usually-confused crash test dummy here...)
>
> > Well I spent a lot of time making the x86-64 timing code work
> > well on a variety of machines; working around a wide
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> > If that isn't possible it needs very careful review which just hasn't
> > happened yet. But I'm not convinced even step by step is not possible
> > here.
>
> There is no step by step thing. You convert an arch to clock events or
> you convert it
On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
(Note - I'm just a usually-confused crash test dummy here...)
> Well I spent a lot of time making the x86-64 timing code work
> well on a variety of machines; working around a wide variety
> of hardware and platform bugs. I obviously don't
Andi,
On Wed, 2007-07-11 at 23:16 +0200, Andi Kleen wrote:
> > What contribution do we have from you instead? A week before the .23
>
> I told him my objections privately earlier. Basically i would
> like to see an actually debuggable step-by-step change, not a rip everything
> out.
You
Hi Andi,
On Wed, Jul 11, 2007 at 11:16:38PM +0200, Andi Kleen wrote:
> I thought it was clear that rip everything out is rarely a good idea
> in Linux land? That's really not something I should need to harp on
> repeatedly.
I'm going to change topic big time because your sentence above
On Wed, 11 Jul 2007, Ingo Molnar wrote:
>
> What you just did here is a slap in the face to a lot of contributors
> who worked hard on this code :(
Ingo, I'm sorry to say so, but your answer just convinced me that you're
wrong, and we MUST NOT take that code.
That was *exactly* the same
Randy,
On Wed, 2007-07-11 at 14:02 -0700, Randy Dunlap wrote:
> I certainly haven't. I can barely keep up with reading about 1/2
> of lkml emails. And in my non-scientific method, I think that we
> are suffering from both (a) more patch submittals and (b) fewer
> qualified reviewers (per
Well I spent a lot of time making the x86-64 timing code work
well on a variety of machines; working around a wide variety
of hardware and platform bugs. I obviously don't agree on your description
of its maintenance state.
> What contribution do we have from you instead? A week before the .23
On Wed, 11 Jul 2007 19:42:52 +0200 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > clockevents-fix-typo-in-acpi_pmc.patch
> > > timekeeping-fixup-shadow-variable-argument.patch
> > > timerc-cleanup-recently-introduced-whitespace-damage.patch
> > >
Andi Kleen wrote:
More review:
xen-fix-x86-config-dependencies.patch
xen-suppress-abs-symbol-warnings-for-unused-reloc-pointers.patch
xen-cant-support-numa-yet.patch
The first and third of these are just simple Kconfig updates, and the
middle one just updates the list of symbols
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > clockevents-fix-typo-in-acpi_pmc.patch
> > timekeeping-fixup-shadow-variable-argument.patch
> > timerc-cleanup-recently-introduced-whitespace-damage.patch
> > clockevents-remove-prototypes-of-removed-functions.patch
> >
> > i386-trim-memory-not-covered-by-wb-mtrrs.patch
>
> Might need more testing?
For the mtrr trim patch at least, I think the coverage we've received
in -mm is probably sufficient (the failure mode would be fairly
obvious). The only thing I'm nervous about is adding AMD support for
the quirk,
Andrew Morton <[EMAIL PROTECTED]> writes:
> revert-x86_64-mm-verify-cpu-rename.patch
> add-kstrndup-fix.patch
> xen-build-fix.patch
> fix-x86_64-numa-fake-apicid_to_node-mapping-for-fake-numa-2.patch
> fix-x86_64-mm-xen-xen-smp-guest-support.patch
>
Andrew Morton [EMAIL PROTECTED] writes:
revert-x86_64-mm-verify-cpu-rename.patch
add-kstrndup-fix.patch
xen-build-fix.patch
fix-x86_64-numa-fake-apicid_to_node-mapping-for-fake-numa-2.patch
fix-x86_64-mm-xen-xen-smp-guest-support.patch
more-fix-x86_64-mm-xen-xen-smp-guest-support.patch
i386-trim-memory-not-covered-by-wb-mtrrs.patch
Might need more testing?
For the mtrr trim patch at least, I think the coverage we've received
in -mm is probably sufficient (the failure mode would be fairly
obvious). The only thing I'm nervous about is adding AMD support for
the quirk,
* Andi Kleen [EMAIL PROTECTED] wrote:
clockevents-fix-typo-in-acpi_pmc.patch
timekeeping-fixup-shadow-variable-argument.patch
timerc-cleanup-recently-introduced-whitespace-damage.patch
clockevents-remove-prototypes-of-removed-functions.patch
clockevents-fix-resume-logic.patch
Andi Kleen wrote:
More review:
xen-fix-x86-config-dependencies.patch
xen-suppress-abs-symbol-warnings-for-unused-reloc-pointers.patch
xen-cant-support-numa-yet.patch
The first and third of these are just simple Kconfig updates, and the
middle one just updates the list of symbols
On Wed, 11 Jul 2007 19:42:52 +0200 Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
clockevents-fix-typo-in-acpi_pmc.patch
timekeeping-fixup-shadow-variable-argument.patch
timerc-cleanup-recently-introduced-whitespace-damage.patch
Well I spent a lot of time making the x86-64 timing code work
well on a variety of machines; working around a wide variety
of hardware and platform bugs. I obviously don't agree on your description
of its maintenance state.
What contribution do we have from you instead? A week before the .23
Randy,
On Wed, 2007-07-11 at 14:02 -0700, Randy Dunlap wrote:
I certainly haven't. I can barely keep up with reading about 1/2
of lkml emails. And in my non-scientific method, I think that we
are suffering from both (a) more patch submittals and (b) fewer
qualified reviewers (per kernel
On Wed, 11 Jul 2007, Ingo Molnar wrote:
What you just did here is a slap in the face to a lot of contributors
who worked hard on this code :(
Ingo, I'm sorry to say so, but your answer just convinced me that you're
wrong, and we MUST NOT take that code.
That was *exactly* the same thing
Hi Andi,
On Wed, Jul 11, 2007 at 11:16:38PM +0200, Andi Kleen wrote:
I thought it was clear that rip everything out is rarely a good idea
in Linux land? That's really not something I should need to harp on
repeatedly.
I'm going to change topic big time because your sentence above
perfectly
On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
(Note - I'm just a usually-confused crash test dummy here...)
Well I spent a lot of time making the x86-64 timing code work
well on a variety of machines; working around a wide variety
of hardware and platform bugs. I obviously don't agree
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
If that isn't possible it needs very careful review which just hasn't
happened yet. But I'm not convinced even step by step is not possible
here.
There is no step by step thing. You convert an arch to clock events or
you convert it not.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
(Note - I'm just a usually-confused crash test dummy here...)
Well I spent a lot of time making the x86-64 timing code work
well on a variety of machines; working around a wide variety
of
Linus,
On Wed, 2007-07-11 at 14:42 -0700, Linus Torvalds wrote:
Here's a big clue: it doesn't matter one _whit_ how much face-slapping you
get, or how much effort some programmers have put into the code. It's
untested. And no, we are *not* going to do another rip everything out,
and
On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
I'm going to change topic big time because your sentence above
perfectly applies to the O(1) scheduler too.
I disagree to a large degree.
We almost never have problems with code you can think about.
Sure, bugs happen, but code that everybody
On Wed, 11 Jul 2007 14:54:12 PDT, Chris Wright said:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
(Note - I'm just a usually-confused crash test dummy here...)
Well I spent a lot of time making the x86-64 timing code work
well on
On Wed, 11 Jul 2007, [EMAIL PROTECTED] wrote:
Odd, I looked at the patchset fairly closely a number of times, as I was
hand-retrofitting the -rc[1-4] versions onto -rc[1-4]-mm kernels, and it
looked
to *me* like it was a nice set of 20 or so step-by-step changes (bisectable
and
On Wed, Jul 11, 2007 at 11:46:41PM +0200, Thomas Gleixner wrote:
Andi,
On Wed, 2007-07-11 at 23:16 +0200, Andi Kleen wrote:
What contribution do we have from you instead? A week before the .23
I told him my objections privately earlier. Basically i would
like to see an actually
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Andrew - how do you feel about keeping this in the -mm tree until Linus,
Andi, Ingo, and Thomas get on the same page (which may be around the 2.6.24
merge window, by my guesstimate)?
Well, that's supposed to be Andi's tree and aggregated by Andrew
On Thu, 12 Jul 2007, Thomas Gleixner wrote:
Can you please shed some light on me, how exactly you switch an
architecture gradually to clock events.
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
On Wed, 11 Jul 2007, [EMAIL PROTECTED] wrote:
Takes a closer look at the patches D'Oh! :) Yeah, the -rc4 version I'm
looking at is like a dozen 1-3K patches setting up and cleaning up, and then
one monster 65K patch doing the clockevents conversion, then another 6 or 8
small ones.
Linus,
On Wed, 2007-07-11 at 15:20 -0700, Linus Torvalds wrote:
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
interfaces around - and basically guarantee that _zero_ hardware-specific
issues pop up
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
interfaces around - and basically guarantee that _zero_ hardware-specific
issues pop up when you switch over,
On Wed, 11 Jul 2007, Chris Wright wrote:
That's not quite right. Leaving the code unchanged caused breakage
already. The PIT is damn stupid and can be sensitive to how quickly it's
programmed. So code that enable/disable didn't change, but frequency
with which it is called did and broke
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
The HPET change, which is the larger part of the conversion set simply
because we now share the code with i386, might be split out by disabling
HPET in the first step, doing the PIT / APIC conversion and then the
HPET one in a separate step.
The
On Thu, 12 Jul 2007, Thomas Gleixner wrote:
The HPET change, which is the larger part of the conversion set simply
because we now share the code with i386, might be split out by disabling
HPET in the first step, doing the PIT / APIC conversion and then the
HPET one in a separate step.
But
On Wed, 11 Jul 2007 23:39:19 +0200 Thomas Gleixner wrote:
Randy,
On Wed, 2007-07-11 at 14:02 -0700, Randy Dunlap wrote:
I certainly haven't. I can barely keep up with reading about 1/2
of lkml emails. And in my non-scientific method, I think that we
are suffering from both (a) more
* Linus Torvalds [EMAIL PROTECTED] wrote:
That was *exactly* the same thing you talked about when I refused to
take the original timer changes into 2.6.20. You were talking about
how lots of people had worked really hard, and how it was really
tested.
yes - i was (way too!) upset about
Linus,
On Wed, 2007-07-11 at 16:07 -0700, Linus Torvalds wrote:
Why not just fix up the HPET code so that it can be shared *first*.
Without the other conversion? Really - What's so wrong with the hpet.c
changes in the *absense* of conversion to clockevents? Those changes seem
to be totally
The same is true of a lot of the APIC timer code. Sure, that patch has the
actual conversion in it, and you don't have the cross-architecture issues,
but more than 50% of the patch seems to be just cleanup that is
independent of the actual switch-over, no?
I don't think it's that much
On Thu, 12 Jul 2007, Ingo Molnar wrote:
We also integrated _all_ feedback we got, and we had the capacity and
capability to fix whatever other feedback comes back - it just never
came ... until today.
One thing I'll happily talk about is that while 2.6.21 was painful, you
and Thomas in
Andi,
On Thu, 2007-07-12 at 01:36 +0200, Andi Kleen wrote:
The same is true of a lot of the APIC timer code. Sure, that patch has the
actual conversion in it, and you don't have the cross-architecture issues,
but more than 50% of the patch seems to be just cleanup that is
independent
* Andi Kleen [EMAIL PROTECTED] wrote:
The same is true of a lot of the APIC timer code. Sure, that patch
has the actual conversion in it, and you don't have the
cross-architecture issues, but more than 50% of the patch seems to
be just cleanup that is independent of the actual
i dont think clean, modern x86 code will ever happen - x86_64 has and
is going to have the exact same type of crap. And i'll say a weird thing
Yes, but it will be new crap, but no old crap anymore.
If you always pile the new crap on the old crap at some point
the whole thing might fall over.
* Andi Kleen ([EMAIL PROTECTED]) wrote:
The equivalent to the powerpc way would be essentially to report i386
into the x86-64 code base and leave the really old hardware only
in arch/i386. I've considered doing it, but it would be an awful
lot of work and to tempt distributions to actually use
* Andi Kleen [EMAIL PROTECTED] wrote:
i dont think clean, modern x86 code will ever happen - x86_64 has
and is going to have the exact same type of crap. And i'll say a
weird thing
Yes, but it will be new crap, but no old crap anymore.
If you always pile the new crap on the old
On Thu, Jul 12, 2007 at 02:18:07AM +0200, Ingo Molnar wrote:
i dont think clean, modern x86 code will ever happen - x86_64 has
and is going to have the exact same type of crap. And i'll say a
weird thing
Yes, but it will be new crap, but no old crap anymore.
If you always pile
On Wed, 2007-07-11 at 15:58 -0700, Linus Torvalds wrote:
On Wed, 11 Jul 2007, Chris Wright wrote:
That's not quite right. Leaving the code unchanged caused breakage
already. The PIT is damn stupid and can be sensitive to how quickly it's
programmed. So code that enable/disable
93 matches
Mail list logo
