Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Thomas Gleixner ([EMAIL PROTECTED]) wrote: > On Mon, 2007-04-02 at 14:39 -0700, Chris Wright wrote: > > the part i know is broken is lapic broadcast, so i'd like to fix that > > up too. trouble is, it's broken on vanilla too, so i'm not 100% sure > > what i'm debugging yet. > > You need to remove switch_APIC_timer_to_ipi and counterpart so that the > clockevents broadcast gets control over broadcasting. This requires a > change in drivers/acpi/processor_idle.c as well > > commit e9e2cdb412412326c4827fc78ba27f410d837e6e has the basic changes. Yeah, I saw that, and while I didn't remove it yet, it shouldn't be getting called from anywhere because of CONFIG_GENERIC_CLOCKEVENTS being set. In fact, acpi_propagate_timer_broadcast() does get called, and all that does it drop me back to hpet because of C3. But, I didn't add DUMMY yet, and I must've missed smth else. Some of that got a little tangled into the nice calibration cleanup, which I didn't want to suck in until I understood what I had broken ;-) thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
On Mon, 2007-04-02 at 14:39 -0700, Chris Wright wrote: > > > Yes, that's part of why I did some of the cleanups that way, so that we > > > could merge the two together later. > > > > I'd prefer to get this done now. If we plug it in as is, the "merge > > later" probably will never happen. > > that's fine, this is just RFC to see if there's obvious broken bits, etc. > also, i still need to do some split out of the pit. it and hpet are nearly > identical though, so i don't noticing any issues with this. Ok. > the part i know is broken is lapic broadcast, so i'd like to fix that > up too. trouble is, it's broken on vanilla too, so i'm not 100% sure > what i'm debugging yet. You need to remove switch_APIC_timer_to_ipi and counterpart so that the clockevents broadcast gets control over broadcasting. This requires a change in drivers/acpi/processor_idle.c as well commit e9e2cdb412412326c4827fc78ba27f410d837e6e has the basic changes. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Thomas Gleixner ([EMAIL PROTECTED]) wrote: > On Sun, 2007-04-01 at 11:54 -0700, Chris Wright wrote: > > * Thomas Gleixner ([EMAIL PROTECTED]) wrote: > > > On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote: > > > > This series converts x86_64 timers to clockevents drivers > > > > and then enables dynticks. There's some minor cleanups along > > > > the way. The lapic broadcast mechanism is untested, I'm sure it > > > > still needs work, there's still some cruft in lapic_setup_timer. > > > > > > > > This is just for comments at this point, now that it's working > > > > on my test box in both NO_HZ=n and NO_HZ=n configurations (typically > > > > using hpet). > > > > > > Have you checked, if we could share the code between i386 and x86_64 at > > > least for PIT and HPET. I'm not sure about the local APIC, but I think > > > it might be doable as well. > > > > Yes, that's part of why I did some of the cleanups that way, so that we > > could merge the two together later. > > I'd prefer to get this done now. If we plug it in as is, the "merge > later" probably will never happen. that's fine, this is just RFC to see if there's obvious broken bits, etc. also, i still need to do some split out of the pit. it and hpet are nearly identical though, so i don't noticing any issues with this. the part i know is broken is lapic broadcast, so i'd like to fix that up too. trouble is, it's broken on vanilla too, so i'm not 100% sure what i'm debugging yet. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
On Sun, 2007-04-01 at 11:54 -0700, Chris Wright wrote: > * Thomas Gleixner ([EMAIL PROTECTED]) wrote: > > On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote: > > > This series converts x86_64 timers to clockevents drivers > > > and then enables dynticks. There's some minor cleanups along > > > the way. The lapic broadcast mechanism is untested, I'm sure it > > > still needs work, there's still some cruft in lapic_setup_timer. > > > > > > This is just for comments at this point, now that it's working > > > on my test box in both NO_HZ=n and NO_HZ=n configurations (typically > > > using hpet). > > > > Have you checked, if we could share the code between i386 and x86_64 at > > least for PIT and HPET. I'm not sure about the local APIC, but I think > > it might be doable as well. > > Yes, that's part of why I did some of the cleanups that way, so that we > could merge the two together later. I'd prefer to get this done now. If we plug it in as is, the "merge later" probably will never happen. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
On Sun, 2007-04-01 at 22:53 +0200, Andi Kleen wrote: > > Have you checked, if we could share the code between i386 and x86_64 at > > least for PIT and HPET. I'm not sure about the local APIC, but I think > > it might be doable as well. > > Not for PIT. I don't want all the broken ancient hardware workarounds on > x86-64. Err, what are you talking about ? The clock events code in arch/i386/kernel/i8253.c does not have any quirks. It's straight forward. The only quirk is in pit_read() and we can simply make it depend on !64bit. > HPET might be doable, but would need quite some work. Right, but this is better spent than having two implementations of the same thing around. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
> Have you checked, if we could share the code between i386 and x86_64 at > least for PIT and HPET. I'm not sure about the local APIC, but I think > it might be doable as well. Not for PIT. I don't want all the broken ancient hardware workarounds on x86-64. HPET might be doable, but would need quite some work. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Thomas Gleixner ([EMAIL PROTECTED]) wrote: > On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote: > > This series converts x86_64 timers to clockevents drivers > > and then enables dynticks. There's some minor cleanups along > > the way. The lapic broadcast mechanism is untested, I'm sure it > > still needs work, there's still some cruft in lapic_setup_timer. > > > > This is just for comments at this point, now that it's working > > on my test box in both NO_HZ=n and NO_HZ=n configurations (typically > > using hpet). > > Have you checked, if we could share the code between i386 and x86_64 at > least for PIT and HPET. I'm not sure about the local APIC, but I think > it might be doable as well. Yes, that's part of why I did some of the cleanups that way, so that we could merge the two together later. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote: > This series converts x86_64 timers to clockevents drivers > and then enables dynticks. There's some minor cleanups along > the way. The lapic broadcast mechanism is untested, I'm sure it > still needs work, there's still some cruft in lapic_setup_timer. > > This is just for comments at this point, now that it's working > on my test box in both NO_HZ=n and NO_HZ=n configurations (typically > using hpet). Have you checked, if we could share the code between i386 and x86_64 at least for PIT and HPET. I'm not sure about the local APIC, but I think it might be doable as well. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Chris Wright <[EMAIL PROTECTED]> wrote: > > hm, neat - did you take a look at the x86_64 clockevents code that > > is in -rt and that has been there for a year or so and has been > > tested quite extensively? > > Yes, that's what I started with. [...] ok :) > [...] It was only partially done, for example, didn't have hpet done > yet and didn't work well on my machine (hang on boot). As I dug at > it, there was still more room for cleanups, etc. Hence this, which has > also been tested somewhat extensively as Jeremy noted from my typo > above... Both NO_HZ=n _and_ NO_HZ=n ;-) good :) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > * Chris Wright <[EMAIL PROTECTED]> wrote: > > This series converts x86_64 timers to clockevents drivers and then > > enables dynticks. There's some minor cleanups along the way. The > > lapic broadcast mechanism is untested, I'm sure it still needs work, > > there's still some cruft in lapic_setup_timer. > > > > This is just for comments at this point, now that it's working on my > > test box in both NO_HZ=n and NO_HZ=n configurations (typically using > > hpet). > > hm, neat - did you take a look at the x86_64 clockevents code that is in > -rt and that has been there for a year or so and has been tested quite > extensively? Yes, that's what I started with. It was only partially done, for example, didn't have hpet done yet and didn't work well on my machine (hang on boot). As I dug at it, there was still more room for cleanups, etc. Hence this, which has also been tested somewhat extensively as Jeremy noted from my typo above... Both NO_HZ=n _and_ NO_HZ=n ;-) thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] x86_64: enable clockevents and dynticks
* Chris Wright <[EMAIL PROTECTED]> wrote: > This series converts x86_64 timers to clockevents drivers and then > enables dynticks. There's some minor cleanups along the way. The > lapic broadcast mechanism is untested, I'm sure it still needs work, > there's still some cruft in lapic_setup_timer. > > This is just for comments at this point, now that it's working on my > test box in both NO_HZ=n and NO_HZ=n configurations (typically using > hpet). hm, neat - did you take a look at the x86_64 clockevents code that is in -rt and that has been there for a year or so and has been tested quite extensively? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
