Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Tony Lindgren wrote: > * Pavel Machek <[EMAIL PROTECTED]> [050419 14:10]: >>Hi! >> >>>The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states. >>>The machine run at 2.00 GHz all the time. >>.. >>>_passing bm_history=0x (default) to processor module:_ >>> >>>Average current the last 470 seconds: *1986mA* (also measured better >>>values ~1800, does battery level play a role?!?) >>Probably yes. If voltage changes, 2000mA means different ammount of power. > > Thomas, thanks for doing all the stats and patches to squeeze some > real power savings out of this! :) > > We should display both average mA and average Watts with pmstats. > BTW, I've posted Thomas' version of pmstats as pmstats-0.2.gz to > muru.com also. > >>>(cmp. >>>ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) >>> >>> >>>_passing bm_history=0xFF to processor module:_ >>> >>>Average current the last 190 seconds: *1757mA* >>>(cmp. >>>ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) >>>(Usage count could be bogus, as some invokations could not succeed >>>if bm has currently been active). >>Ok. >> >>>idle_ms == 100, bm_promote_bs == 30 >>>Average current the last 80 seconds: *1466mA* >>>(cmp. >>>ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) >>Very nice indeed. That seems like ~5W saved, right? That might give >>you one more hour of battery life > > Depending on your battery capacity. But looking at the average Watts > on the first 8 lines of the two stats above: > > 1000_HZ_bm_history_: > (21.43 + 23.32 + 23.32 + 21.71 + 21.71 + 23.84 + 23.84 + 22.62) / 8 > = 22.724W > > tony_dyn_tick_processor_idle_100_bm_30: > (16.07 + 16.07 + 16.00 + 16.00 + 16.08 + 16.08 + 16.29 + 16.29) / 8 > = 16.11W > > And then comparing these two: > 22.72 / 16.11 = 1.4103 > > So according to my calculations this should provide about 1.4 times > longer battery life compared to what you were getting earlier... > That is assuming system is mostly idle, of course. > Be aware that speedstep was off (2.0 GHz). When CPU frequency is controlled you won't have that much enhancement anymore ... Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Tony Lindgren wrote: * Pavel Machek [EMAIL PROTECTED] [050419 14:10]: Hi! The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states. The machine run at 2.00 GHz all the time. .. _passing bm_history=0x (default) to processor module:_ Average current the last 470 seconds: *1986mA* (also measured better values ~1800, does battery level play a role?!?) Probably yes. If voltage changes, 2000mA means different ammount of power. Thomas, thanks for doing all the stats and patches to squeeze some real power savings out of this! :) We should display both average mA and average Watts with pmstats. BTW, I've posted Thomas' version of pmstats as pmstats-0.2.gz to muru.com also. (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) _passing bm_history=0xFF to processor module:_ Average current the last 190 seconds: *1757mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) (Usage count could be bogus, as some invokations could not succeed if bm has currently been active). Ok. idle_ms == 100, bm_promote_bs == 30 Average current the last 80 seconds: *1466mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) Very nice indeed. That seems like ~5W saved, right? That might give you one more hour of battery life Depending on your battery capacity. But looking at the average Watts on the first 8 lines of the two stats above: 1000_HZ_bm_history_: (21.43 + 23.32 + 23.32 + 21.71 + 21.71 + 23.84 + 23.84 + 22.62) / 8 = 22.724W tony_dyn_tick_processor_idle_100_bm_30: (16.07 + 16.07 + 16.00 + 16.00 + 16.08 + 16.08 + 16.29 + 16.29) / 8 = 16.11W And then comparing these two: 22.72 / 16.11 = 1.4103 So according to my calculations this should provide about 1.4 times longer battery life compared to what you were getting earlier... That is assuming system is mostly idle, of course. Be aware that speedstep was off (2.0 GHz). When CPU frequency is controlled you won't have that much enhancement anymore ... Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
* Pavel Machek <[EMAIL PROTECTED]> [050419 14:10]: > Hi! > > > The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power > > states. > > The machine run at 2.00 GHz all the time. > .. > > _passing bm_history=0x (default) to processor module:_ > > > > Average current the last 470 seconds: *1986mA* (also measured better > > values ~1800, does battery level play a role?!?) > > Probably yes. If voltage changes, 2000mA means different ammount of power. Thomas, thanks for doing all the stats and patches to squeeze some real power savings out of this! :) We should display both average mA and average Watts with pmstats. BTW, I've posted Thomas' version of pmstats as pmstats-0.2.gz to muru.com also. > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) > > > > > > _passing bm_history=0xFF to processor module:_ > > > > Average current the last 190 seconds: *1757mA* > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) > > (Usage count could be bogus, as some invokations could not succeed > > if bm has currently been active). > > Ok. > > > idle_ms == 100, bm_promote_bs == 30 > > Average current the last 80 seconds: *1466mA* > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) > > Very nice indeed. That seems like ~5W saved, right? That might give > you one more hour of battery life Depending on your battery capacity. But looking at the average Watts on the first 8 lines of the two stats above: 1000_HZ_bm_history_: (21.43 + 23.32 + 23.32 + 21.71 + 21.71 + 23.84 + 23.84 + 22.62) / 8 = 22.724W tony_dyn_tick_processor_idle_100_bm_30: (16.07 + 16.07 + 16.00 + 16.00 + 16.08 + 16.08 + 16.29 + 16.29) / 8 = 16.11W And then comparing these two: 22.72 / 16.11 = 1.4103 So according to my calculations this should provide about 1.4 times longer battery life compared to what you were getting earlier... That is assuming system is mostly idle, of course. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Dominik Brodowski wrote: > On Tue, Apr 19, 2005 at 11:03:30PM +0200, Thomas Renninger wrote: >>>"All" we need to do is to update the "diff". Without dynamic ticks, if the >>>idle loop didn't get called each jiffy, it was a big hint that there was so >>>much activity in between, and if there is activity, there is most likely >>>also bus master activity, or at least more work to do, so interrupt activity >>>is likely. Therefore we assume there was bm_activity even if there was none. >>> >>If I understand this right you want at least wait 32 (or whatever value) ms >>if there was bm activity, >>before it is allowed to trigger C3/C4? > > That's the theory of operation of the current algorithm. I think that we > should do that small change to the current algorithm which allows us to keep > C3/C4 working with dyn-idle first, and then think of a very small abstraction > layer to test different idle algroithms, and -- possibly -- use different > ones for different usages. > >>I think the problem is (at least I made the experience with this particular >>machine) that bm activity comes very often and regularly (each 30-150ms?). >> >>I think the approach to directly adjust the latency to a deeper sleep state >>if the >>average bus master and OS activity is low is very efficient. >> >>Because I don't consider whether there was bm_activity the last ms, I only >>consider the average, it seems to happen that I try to trigger >>C3/C4 when there is just something copied and some bm active ?!? > > I don't think that this is perfect behaviour: if the system is idle, and > there is _currently_ bus master activity, the CPU should be put into C1 or > C2 type sleep. If you select C3 and actually enter it, you're risking > DMA issues, AFAICS. > On my system triggering C3/C4 is just ignored (sleep_ticks < 0). These ignorings (C3/C4 failures) seem to directly depend on how much bm_activity there actually is. With the current method (wait at least 30 ms if there was bm activity before triggering C3/C4) these failures never happened. As mentioned using bm_promotion_ms you can lower the failures, but never reach zero. If these failures lead to system freezes on other systems, my next sentence is valid (I meant my patch). >>The patch is useless if these failures end up in system freezes on >>other machines... > > I know that my patch is useless in its current form, but I wanted to share > it as a different way of doing things. > >>The problem with the old approach is, that after (doesn't matter C1-Cx) >>sleep and dyn_idle_tick, the chance to wake up because of bm activity is >>very likely. >>You enter idle() again -> there was bm_activity -> C2. Wake up after e.g. >>50ms, because of bm_activity again (bm_sts bit set) -> stay in C2, wake up >>after 40ms -> bm activity... You only have the chance to get into deeper >>states if the sleeps are interrupted by an interrupt, not bm activity. > > That's a side-effect, indeed. However: if there _is_ bus master activity, we > must not enter C3, AFAICS. > What about a mixed approach: only reprogram timer if you want to go to deeper sleeping states (C3-Cx) when bm activity comes in place? It's the only way you can say: the last xy ms there was no bm activity (use bm_history), now it's safe to sleep and also be efficient: don't sleep forever in C1/C2 -> bm_sts bit will probably be set afterwards and you need to wait another xy ms in C1/C2 -> endless loop ... Like that the timer is only disabled where it is really useful, on C3-Cx machines (or are there other cases?). Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi, On Wed, Apr 20, 2005 at 02:08:46PM +0200, Pavel Machek wrote: > Like "ipw2x00 looses packets" if this happens too often? See "PCI latency error if C3 enabled" on http://ipw2100.sf.net -- it causes network instability, frequent firmware restarts. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! > > > > Because I don't consider whether there was bm_activity the last ms, I > > > > only > > > > consider the average, it seems to happen that I try to trigger > > > > C3/C4 when there is just something copied and some bm active ?!? > > > > > > I don't think that this is perfect behaviour: if the system is idle, and > > > there is _currently_ bus master activity, the CPU should be put into C1 or > > > C2 type sleep. If you select C3 and actually enter it, you're risking > > > DMA issues, AFAICS. > > > > What kinds of DMA issues? Waiting 32msec or so is only heuristic; it > > can go wrong any time. It would be really bad if it corrupted data or > > something like that. > > loop() >a) bus mastering activity is going on at the very moment >b) the CPU is entering C3 >c) the CPU is woken out of C3 because of bus mastering activity > > the repeated delay between b) and c) might be problematic, as can be seen > by the comment in processor_idle.c: > > * TBD: A better policy might be to fallback to the demotion > * state (use it for this quantum only) istead of > * demoting -- and rely on duration as our sole demotion > * qualification. This may, however, introduce DMA > * issues (e.g. floppy DMA transfer overrun/underrun). > */ > > I'm not so worried about floppy DMA but about the ipw2x00 issues here. Like "ipw2x00 looses packets" if this happens too often? Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Wed, Apr 20, 2005 at 01:57:39PM +0200, Pavel Machek wrote: > Hi! > > > > Because I don't consider whether there was bm_activity the last ms, I only > > > consider the average, it seems to happen that I try to trigger > > > C3/C4 when there is just something copied and some bm active ?!? > > > > I don't think that this is perfect behaviour: if the system is idle, and > > there is _currently_ bus master activity, the CPU should be put into C1 or > > C2 type sleep. If you select C3 and actually enter it, you're risking > > DMA issues, AFAICS. > > What kinds of DMA issues? Waiting 32msec or so is only heuristic; it > can go wrong any time. It would be really bad if it corrupted data or > something like that. loop() a) bus mastering activity is going on at the very moment b) the CPU is entering C3 c) the CPU is woken out of C3 because of bus mastering activity the repeated delay between b) and c) might be problematic, as can be seen by the comment in processor_idle.c: * TBD: A better policy might be to fallback to the demotion * state (use it for this quantum only) istead of * demoting -- and rely on duration as our sole demotion * qualification. This may, however, introduce DMA * issues (e.g. floppy DMA transfer overrun/underrun). */ I'm not so worried about floppy DMA but about the ipw2x00 issues here. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! > > Because I don't consider whether there was bm_activity the last ms, I only > > consider the average, it seems to happen that I try to trigger > > C3/C4 when there is just something copied and some bm active ?!? > > I don't think that this is perfect behaviour: if the system is idle, and > there is _currently_ bus master activity, the CPU should be put into C1 or > C2 type sleep. If you select C3 and actually enter it, you're risking > DMA issues, AFAICS. What kinds of DMA issues? Waiting 32msec or so is only heuristic; it can go wrong any time. It would be really bad if it corrupted data or something like that. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Tue, Apr 19, 2005 at 11:03:30PM +0200, Thomas Renninger wrote: > > "All" we need to do is to update the "diff". Without dynamic ticks, if the > > idle loop didn't get called each jiffy, it was a big hint that there was so > > much activity in between, and if there is activity, there is most likely > > also bus master activity, or at least more work to do, so interrupt activity > > is likely. Therefore we assume there was bm_activity even if there was none. > > > If I understand this right you want at least wait 32 (or whatever value) ms > if there was bm activity, > before it is allowed to trigger C3/C4? That's the theory of operation of the current algorithm. I think that we should do that small change to the current algorithm which allows us to keep C3/C4 working with dyn-idle first, and then think of a very small abstraction layer to test different idle algroithms, and -- possibly -- use different ones for different usages. > I think the problem is (at least I made the experience with this particular > machine) that bm activity comes very often and regularly (each 30-150ms?). > > I think the approach to directly adjust the latency to a deeper sleep state > if the > average bus master and OS activity is low is very efficient. > > Because I don't consider whether there was bm_activity the last ms, I only > consider the average, it seems to happen that I try to trigger > C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. > The patch is useless if these failures end up in system freezes on > other machines... I know that my patch is useless in its current form, but I wanted to share it as a different way of doing things. > The problem with the old approach is, that after (doesn't matter C1-Cx) > sleep and dyn_idle_tick, the chance to wake up because of bm activity is > very likely. > You enter idle() again -> there was bm_activity -> C2. Wake up after e.g. > 50ms, because of bm_activity again (bm_sts bit set) -> stay in C2, wake up > after 40ms -> bm activity... You only have the chance to get into deeper > states if the sleeps are interrupted by an interrupt, not bm activity. That's a side-effect, indeed. However: if there _is_ bus master activity, we must not enter C3, AFAICS. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Tue, Apr 19, 2005 at 11:03:30PM +0200, Thomas Renninger wrote: All we need to do is to update the diff. Without dynamic ticks, if the idle loop didn't get called each jiffy, it was a big hint that there was so much activity in between, and if there is activity, there is most likely also bus master activity, or at least more work to do, so interrupt activity is likely. Therefore we assume there was bm_activity even if there was none. If I understand this right you want at least wait 32 (or whatever value) ms if there was bm activity, before it is allowed to trigger C3/C4? That's the theory of operation of the current algorithm. I think that we should do that small change to the current algorithm which allows us to keep C3/C4 working with dyn-idle first, and then think of a very small abstraction layer to test different idle algroithms, and -- possibly -- use different ones for different usages. I think the problem is (at least I made the experience with this particular machine) that bm activity comes very often and regularly (each 30-150ms?). I think the approach to directly adjust the latency to a deeper sleep state if the average bus master and OS activity is low is very efficient. Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. The patch is useless if these failures end up in system freezes on other machines... I know that my patch is useless in its current form, but I wanted to share it as a different way of doing things. The problem with the old approach is, that after (doesn't matter C1-Cx) sleep and dyn_idle_tick, the chance to wake up because of bm activity is very likely. You enter idle() again - there was bm_activity - C2. Wake up after e.g. 50ms, because of bm_activity again (bm_sts bit set) - stay in C2, wake up after 40ms - bm activity... You only have the chance to get into deeper states if the sleeps are interrupted by an interrupt, not bm activity. That's a side-effect, indeed. However: if there _is_ bus master activity, we must not enter C3, AFAICS. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. What kinds of DMA issues? Waiting 32msec or so is only heuristic; it can go wrong any time. It would be really bad if it corrupted data or something like that. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Wed, Apr 20, 2005 at 01:57:39PM +0200, Pavel Machek wrote: Hi! Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. What kinds of DMA issues? Waiting 32msec or so is only heuristic; it can go wrong any time. It would be really bad if it corrupted data or something like that. loop() a) bus mastering activity is going on at the very moment b) the CPU is entering C3 c) the CPU is woken out of C3 because of bus mastering activity the repeated delay between b) and c) might be problematic, as can be seen by the comment in processor_idle.c: * TBD: A better policy might be to fallback to the demotion * state (use it for this quantum only) istead of * demoting -- and rely on duration as our sole demotion * qualification. This may, however, introduce DMA * issues (e.g. floppy DMA transfer overrun/underrun). */ I'm not so worried about floppy DMA but about the ipw2x00 issues here. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. What kinds of DMA issues? Waiting 32msec or so is only heuristic; it can go wrong any time. It would be really bad if it corrupted data or something like that. loop() a) bus mastering activity is going on at the very moment b) the CPU is entering C3 c) the CPU is woken out of C3 because of bus mastering activity the repeated delay between b) and c) might be problematic, as can be seen by the comment in processor_idle.c: * TBD: A better policy might be to fallback to the demotion * state (use it for this quantum only) istead of * demoting -- and rely on duration as our sole demotion * qualification. This may, however, introduce DMA * issues (e.g. floppy DMA transfer overrun/underrun). */ I'm not so worried about floppy DMA but about the ipw2x00 issues here. Like ipw2x00 looses packets if this happens too often? Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi, On Wed, Apr 20, 2005 at 02:08:46PM +0200, Pavel Machek wrote: Like ipw2x00 looses packets if this happens too often? See PCI latency error if C3 enabled on http://ipw2100.sf.net -- it causes network instability, frequent firmware restarts. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Dominik Brodowski wrote: On Tue, Apr 19, 2005 at 11:03:30PM +0200, Thomas Renninger wrote: All we need to do is to update the diff. Without dynamic ticks, if the idle loop didn't get called each jiffy, it was a big hint that there was so much activity in between, and if there is activity, there is most likely also bus master activity, or at least more work to do, so interrupt activity is likely. Therefore we assume there was bm_activity even if there was none. If I understand this right you want at least wait 32 (or whatever value) ms if there was bm activity, before it is allowed to trigger C3/C4? That's the theory of operation of the current algorithm. I think that we should do that small change to the current algorithm which allows us to keep C3/C4 working with dyn-idle first, and then think of a very small abstraction layer to test different idle algroithms, and -- possibly -- use different ones for different usages. I think the problem is (at least I made the experience with this particular machine) that bm activity comes very often and regularly (each 30-150ms?). I think the approach to directly adjust the latency to a deeper sleep state if the average bus master and OS activity is low is very efficient. Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. On my system triggering C3/C4 is just ignored (sleep_ticks 0). These ignorings (C3/C4 failures) seem to directly depend on how much bm_activity there actually is. With the current method (wait at least 30 ms if there was bm activity before triggering C3/C4) these failures never happened. As mentioned using bm_promotion_ms you can lower the failures, but never reach zero. If these failures lead to system freezes on other systems, my next sentence is valid (I meant my patch). The patch is useless if these failures end up in system freezes on other machines... I know that my patch is useless in its current form, but I wanted to share it as a different way of doing things. The problem with the old approach is, that after (doesn't matter C1-Cx) sleep and dyn_idle_tick, the chance to wake up because of bm activity is very likely. You enter idle() again - there was bm_activity - C2. Wake up after e.g. 50ms, because of bm_activity again (bm_sts bit set) - stay in C2, wake up after 40ms - bm activity... You only have the chance to get into deeper states if the sleeps are interrupted by an interrupt, not bm activity. That's a side-effect, indeed. However: if there _is_ bus master activity, we must not enter C3, AFAICS. What about a mixed approach: only reprogram timer if you want to go to deeper sleeping states (C3-Cx) when bm activity comes in place? It's the only way you can say: the last xy ms there was no bm activity (use bm_history), now it's safe to sleep and also be efficient: don't sleep forever in C1/C2 - bm_sts bit will probably be set afterwards and you need to wait another xy ms in C1/C2 - endless loop ... Like that the timer is only disabled where it is really useful, on C3-Cx machines (or are there other cases?). Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
* Pavel Machek [EMAIL PROTECTED] [050419 14:10]: Hi! The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states. The machine run at 2.00 GHz all the time. .. _passing bm_history=0x (default) to processor module:_ Average current the last 470 seconds: *1986mA* (also measured better values ~1800, does battery level play a role?!?) Probably yes. If voltage changes, 2000mA means different ammount of power. Thomas, thanks for doing all the stats and patches to squeeze some real power savings out of this! :) We should display both average mA and average Watts with pmstats. BTW, I've posted Thomas' version of pmstats as pmstats-0.2.gz to muru.com also. (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) _passing bm_history=0xFF to processor module:_ Average current the last 190 seconds: *1757mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) (Usage count could be bogus, as some invokations could not succeed if bm has currently been active). Ok. idle_ms == 100, bm_promote_bs == 30 Average current the last 80 seconds: *1466mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) Very nice indeed. That seems like ~5W saved, right? That might give you one more hour of battery life Depending on your battery capacity. But looking at the average Watts on the first 8 lines of the two stats above: 1000_HZ_bm_history_: (21.43 + 23.32 + 23.32 + 21.71 + 21.71 + 23.84 + 23.84 + 22.62) / 8 = 22.724W tony_dyn_tick_processor_idle_100_bm_30: (16.07 + 16.07 + 16.00 + 16.00 + 16.08 + 16.08 + 16.29 + 16.29) / 8 = 16.11W And then comparing these two: 22.72 / 16.11 = 1.4103 So according to my calculations this should provide about 1.4 times longer battery life compared to what you were getting earlier... That is assuming system is mostly idle, of course. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! > The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states. > The machine run at 2.00 GHz all the time. .. > _passing bm_history=0x (default) to processor module:_ > > Average current the last 470 seconds: *1986mA* (also measured better > values ~1800, does battery level play a role?!?) Probably yes. If voltage changes, 2000mA means different ammount of power. > (cmp. > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) > > > _passing bm_history=0xFF to processor module:_ > > Average current the last 190 seconds: *1757mA* > (cmp. > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) > (Usage count could be bogus, as some invokations could not succeed > if bm has currently been active). Ok. > idle_ms == 100, bm_promote_bs == 30 > Average current the last 80 seconds: *1466mA* > (cmp. > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) Very nice indeed. That seems like ~5W saved, right? That might give you one more hour of battery life Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Reducing the CC'd people a bit ...
Dominik Brodowski wrote:
> Hi,
>
> On Tue, Apr 19, 2005 at 04:56:56PM +0200, Thomas Renninger wrote:
>>If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
>>three control values (averages of the last 4 measures):
>>
>>a) idle_ms -> if machine was active for longer than this
>> value (avg), the machine is assumed to not be idle
>> and C1 will be triggered.
>>
>>b) bm_promote_ms -> if the avg bus master activity is below
>> this threshold, C2 is invoked.
>>
>>c) sleep_avg (no module param) -> the average sleep time of the
>> last four C2 (or higher) invokations.
>> If a and b does not apply, a C-state will be searched that has
>> the highest latency, but still has a latency below the latest
>> C2 (or higher) sleeping time and average sleeping time value.
>
> I think that we don't need this complication:
>
>>+//#define DEBUG 1
>>+#ifdef DEBUG
>>+#define myPrintk(string, args...) printk(KERN_INFO ""string, ##args);
>>+#else
>>+#define myPrintk(string, args...) {};
>>+#endif
>
> Please don't do that... dprintk() is much more common. Also, then don't
> comment dprintk() out below in the patch...
>
Ok, this patch is far from perfect, I am happy that it finally runs that nice on
my machine.
>> if (pr->flags.bm_check) {
>>- u32 bm_status = 0;
>>- unsigned long diff = jiffies - pr->power.bm_check_timestamp;
>>-
>>- if (diff > 32)
>>- diff = 32;
>>-
>>- while (diff) {
>>- /* if we didn't get called, assume there was busmaster
>>activity */
>>- diff--;
>>- if (diff)
>>- pr->power.bm_activity |= 0x1;
>>- pr->power.bm_activity <<= 1;
>>- }
>
> "All" we need to do is to update the "diff". Without dynamic ticks, if the
> idle loop didn't get called each jiffy, it was a big hint that there was so
> much activity in between, and if there is activity, there is most likely
> also bus master activity, or at least more work to do, so interrupt activity
> is likely. Therefore we assume there was bm_activity even if there was none.
>
If I understand this right you want at least wait 32 (or whatever value) ms if
there was bm activity,
before it is allowed to trigger C3/C4?
I think the problem is (at least I made the experience with this particular
machine)
that bm activity comes very often and regularly (each 30-150ms?).
I think the approach to directly adjust the latency to a deeper sleep state if
the
average bus master and OS activity is low is very efficient.
Because I don't consider whether there was bm_activity the last ms, I only
consider the average, it seems to happen that I try to trigger
C3/C4 when there is just something copied and some bm active ?!? Therefore, it
seems to happen
that triggering C3/C4 fails (sleep_ticks < 0). The value of failures is getting
smaller if I increase
the limit for average bm activity before triggering C3/C4 (bm_promote_ms must
be smaller than average bm activity),
but it never will reach zero.
The patch is useless if these failures end up in system freezes on other
machines...
AFAIK there were a lot of freeze problems with C-states? Don't know, it works
here.
The problem with the old approach is, that after (doesn't matter C1-Cx) sleep
and dyn_idle_tick,
the chance to wake up because of bm activity is very likely.
You enter idle() again -> there was bm_activity -> C2. Wake up after e.g. 50ms,
because
of bm_activity again (bm_sts bit set) -> stay in C2, wake up after 40ms -> bm
activity...
You only have the chance to get into deeper states if the sleeps are
interrupted by an interrupt, not bm activity.
I also thought about only reprogram timer if C1/C2 was successful x times and
no bm activity was detected,
same mechanism as now, then only reprogram timer (dyn tick) for deeper sleep
states -> like that, you
still can be sure the last x ms was no bm activity bit set before going to deep
sleeps.
But I don't know how to do it.
> Now, we do know the jiffy value when we started sleeping. If we use
> ticks_elapsed(t1, t2), convert it to jiffies, and do
> diff = jiffies - (pr->power.bm_check_timestamp + last_sleep_jiffies);
> it should work. I wrote a quick patch to do that, but it locked up my
> notebook, so it is most likely broken; hopefully I'll find some time to debug
> it, if somebody does it earlier, that'd be great, though.
>
> Thanks,
> Dominik
>
>
> Only assume busmaster activity on non-idle ticks if we didn't sleep until
> that jiffy. Needed for dyn-idle.
>
> Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
>
> --- linux/drivers/acpi/processor_idle.c.original 2005-04-10
> 20:04:12.0 +0200
> +++ linux/drivers/acpi/processor_idle.c 2005-04-10 20:14:33.0
> +0200
> @@ -120,6 +120,14 @@
> return ((0x - t1) + t2);
> }
>
> +static inline u32
>
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi,
On Tue, Apr 19, 2005 at 04:56:56PM +0200, Thomas Renninger wrote:
> If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
> three control values (averages of the last 4 measures):
>
> a) idle_ms -> if machine was active for longer than this
>value (avg), the machine is assumed to not be idle
>and C1 will be triggered.
>
> b) bm_promote_ms -> if the avg bus master activity is below
>this threshold, C2 is invoked.
>
> c) sleep_avg (no module param) -> the average sleep time of the
>last four C2 (or higher) invokations.
>If a and b does not apply, a C-state will be searched that has
>the highest latency, but still has a latency below the latest
>C2 (or higher) sleeping time and average sleeping time value.
I think that we don't need this complication:
> +//#define DEBUG 1
> +#ifdef DEBUG
> +#define myPrintk(string, args...) printk(KERN_INFO ""string, ##args);
> +#else
> +#define myPrintk(string, args...) {};
> +#endif
Please don't do that... dprintk() is much more common. Also, then don't
comment dprintk() out below in the patch...
> if (pr->flags.bm_check) {
> - u32 bm_status = 0;
> - unsigned long diff = jiffies - pr->power.bm_check_timestamp;
> -
> - if (diff > 32)
> - diff = 32;
> -
> - while (diff) {
> - /* if we didn't get called, assume there was busmaster
> activity */
> - diff--;
> - if (diff)
> - pr->power.bm_activity |= 0x1;
> - pr->power.bm_activity <<= 1;
> - }
"All" we need to do is to update the "diff". Without dynamic ticks, if the
idle loop didn't get called each jiffy, it was a big hint that there was so
much activity in between, and if there is activity, there is most likely
also bus master activity, or at least more work to do, so interrupt activity
is likely. Therefore we assume there was bm_activity even if there was none.
Now, we do know the jiffy value when we started sleeping. If we use
ticks_elapsed(t1, t2), convert it to jiffies, and do
diff = jiffies - (pr->power.bm_check_timestamp + last_sleep_jiffies);
it should work. I wrote a quick patch to do that, but it locked up my
notebook, so it is most likely broken; hopefully I'll find some time to debug
it, if somebody does it earlier, that'd be great, though.
Thanks,
Dominik
Only assume busmaster activity on non-idle ticks if we didn't sleep until
that jiffy. Needed for dyn-idle.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
--- linux/drivers/acpi/processor_idle.c.original2005-04-10
20:04:12.0 +0200
+++ linux/drivers/acpi/processor_idle.c 2005-04-10 20:14:33.0 +0200
@@ -120,6 +120,14 @@
return ((0x - t1) + t2);
}
+static inline u32
+ticks_to_jiffies (u32 pm_ticks)
+{
+ pm_ticks *= 286;
+ pm_ticks = (pm_ticks >> 10);
+ return (pm_ticks / (USEC_PER_SEC / HZ));
+}
+
static void
acpi_processor_power_activate (
@@ -169,7 +177,7 @@
struct acpi_processor_cx *cx = NULL;
struct acpi_processor_cx *next_state = NULL;
int sleep_ticks = 0;
- u32 t1, t2 = 0;
+ u32 t1, t2, td = 0;
pr = processors[_smp_processor_id()];
if (!pr)
@@ -201,11 +209,13 @@
* for demotion.
*/
if (pr->flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr->power.bm_check_timestamp;
+ u32 bm_status = 0;
+ longdiff = jiffies - pr->power.bm_check_timestamp;
if (diff > 32)
diff = 32;
+ else if (diff < 0)
+ diff = 0;
while (diff) {
/* if we didn't get called, assume there was busmaster
activity */
@@ -293,7 +303,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx->latency_ticks -
C2_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx->latency_ticks - C2_OVERHEAD;
+ pr->power.bm_check_timestamp += ticks_to_jiffies(td);
break;
case ACPI_STATE_C3:
@@ -312,7 +324,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx->latency_ticks -
C3_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx->latency_ticks - C3_OVERHEAD;
+ pr->power.bm_check_timestamp += ticks_to_jiffies(td);
break;
default:
-
To unsubscribe from
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Here are some figures (I used your pmstats):
The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states.
The machine run at 2.00 GHz all the time.
A lot of modules (pcmcia, usb, ...) where loaded, services that could
produce load where stopped -> processor is mostly idle.
_
*Running with 1000Hz:*
_No processor module:_
Average current the last 100 seconds: *2289mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_No_module_loaded)
_passing bm_history=0x (default) to processor module:_
Average current the last 470 seconds: *1986mA* (also measured better values
~1800, does battery level play a role?!?)
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_)
_passing bm_history=0xFF to processor module:_
Average current the last 190 seconds: *1757mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF)
(Usage count could be bogus, as some invokations could not succeed if bm has
currently been active).
_
*Running with CONFIG_NO_IDLE_HZ:*
Patched with
http://www.muru.com/linux/dyntick/patches/patch-dynamic-tick-2.6.12-rc2-050408-1.gz
(With the c-state patch attached applied)
_No processor module:_
Average current the last 80 seconds: *2262mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_No_module_loaded)
idle_ms == 40, bm_promote_bs == 30
Average current the last 160 seconds: *1507mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_30)
idle_ms == 100, bm_promote_bs == 30
Average current the last 80 seconds: *1466mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30)
idle_ms == 40, bm_promote_bs == 50
Average current the last 150 seconds: *1481mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_30)
idle_ms == 40, bm_promote_bs == 10
Average current the last 330 seconds: *1474mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_10)
Hmm, parameters do not influence at all ... (idle_ms should only comes in when
switching between idle/not idle).
_
The measures are based on the /proc/acpi/battery/*/* info and are not very
accurate, but could give an overall picture.
Thomas
P.S.: Not tested, because I have no x86_64 C3 machine, but the patch should
also work reliable with Andi's dyn_tick patch
for x86_64 machines.
Tony: I modified your pmstats to produce an average current value:
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/pmstats
Patch not enough tested, yet.
Should behave the same if compile with !CONFIG_IDLE_HZ.
If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
three control values (averages of the last 4 measures):
a) idle_ms -> if machine was active for longer than this
value (avg), the machine is assumed to not be idle
and C1 will be triggered.
b) bm_promote_ms -> if the avg bus master activity is below
this threshold, C2 is invoked.
c) sleep_avg (no module param) -> the average sleep time of the
last four C2 (or higher) invokations.
If a and b does not apply, a C-state will be searched that has
the highest latency, but still has a latency below the latest
C2 (or higher) sleeping time and average sleeping time value.
ToDo:
Test on other machines (only C2 or C0 support).
Discuss and enhance algorithm.
If it is used this way, average calculations could get MMX optimised.
--- linux-2.6.12-rc2.orig/drivers/acpi/processor_idle.c 2005-04-19 15:03:13.0 +0200
+++ linux-2.6.12-rc2/drivers/acpi/processor_idle.c 2005-04-19 15:17:56.0 +0200
@@ -60,6 +60,22 @@
static unsigned int nocst = 0;
module_param(nocst, uint, );
+static unsigned int idle_ms = 40;
+module_param(idle_ms, uint, 0644);
+MODULE_PARM_DESC(idle_ms, "Promote to lower state if machine stays shorter than x ms not in idle func (avg) [40].");
+
+static unsigned int bm_promote_ms = 30;
+module_param(bm_promote_ms, uint, 0644);
+MODULE_PARM_DESC(bm_promote_ms, "Promote to lower state if avg bm is less than x ms [30].");
+
+//#define DEBUG 1
+#ifdef DEBUG
+#define myPrintk(string, args...) printk(KERN_INFO ""string, ##args);
+#else
+#define myPrintk(string, args...) {};
+#endif
+
+
/*
* bm_history -- bit-mask with a bit per jiffy of bus-master activity
* 1000 HZ: 0x: 32 jiffies = 32ms
@@ -162,6 +178,88 @@
return;
}
+u16 calc_average (u64 last_measures){
+ int x;
+ u16 ret = 0;
+ for (x = 0; x < sizeof(u64)*8;
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Here are some figures (I used your pmstats):
The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states.
The machine run at 2.00 GHz all the time.
A lot of modules (pcmcia, usb, ...) where loaded, services that could
produce load where stopped - processor is mostly idle.
_
*Running with 1000Hz:*
_No processor module:_
Average current the last 100 seconds: *2289mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_No_module_loaded)
_passing bm_history=0x (default) to processor module:_
Average current the last 470 seconds: *1986mA* (also measured better values
~1800, does battery level play a role?!?)
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_)
_passing bm_history=0xFF to processor module:_
Average current the last 190 seconds: *1757mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF)
(Usage count could be bogus, as some invokations could not succeed if bm has
currently been active).
_
*Running with CONFIG_NO_IDLE_HZ:*
Patched with
http://www.muru.com/linux/dyntick/patches/patch-dynamic-tick-2.6.12-rc2-050408-1.gz
(With the c-state patch attached applied)
_No processor module:_
Average current the last 80 seconds: *2262mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_No_module_loaded)
idle_ms == 40, bm_promote_bs == 30
Average current the last 160 seconds: *1507mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_30)
idle_ms == 100, bm_promote_bs == 30
Average current the last 80 seconds: *1466mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30)
idle_ms == 40, bm_promote_bs == 50
Average current the last 150 seconds: *1481mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_30)
idle_ms == 40, bm_promote_bs == 10
Average current the last 330 seconds: *1474mA*
(cmp.
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_40_bm_10)
Hmm, parameters do not influence at all ... (idle_ms should only comes in when
switching between idle/not idle).
_
The measures are based on the /proc/acpi/battery/*/* info and are not very
accurate, but could give an overall picture.
Thomas
P.S.: Not tested, because I have no x86_64 C3 machine, but the patch should
also work reliable with Andi's dyn_tick patch
for x86_64 machines.
Tony: I modified your pmstats to produce an average current value:
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/pmstats
Patch not enough tested, yet.
Should behave the same if compile with !CONFIG_IDLE_HZ.
If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
three control values (averages of the last 4 measures):
a) idle_ms - if machine was active for longer than this
value (avg), the machine is assumed to not be idle
and C1 will be triggered.
b) bm_promote_ms - if the avg bus master activity is below
this threshold, C2 is invoked.
c) sleep_avg (no module param) - the average sleep time of the
last four C2 (or higher) invokations.
If a and b does not apply, a C-state will be searched that has
the highest latency, but still has a latency below the latest
C2 (or higher) sleeping time and average sleeping time value.
ToDo:
Test on other machines (only C2 or C0 support).
Discuss and enhance algorithm.
If it is used this way, average calculations could get MMX optimised.
--- linux-2.6.12-rc2.orig/drivers/acpi/processor_idle.c 2005-04-19 15:03:13.0 +0200
+++ linux-2.6.12-rc2/drivers/acpi/processor_idle.c 2005-04-19 15:17:56.0 +0200
@@ -60,6 +60,22 @@
static unsigned int nocst = 0;
module_param(nocst, uint, );
+static unsigned int idle_ms = 40;
+module_param(idle_ms, uint, 0644);
+MODULE_PARM_DESC(idle_ms, Promote to lower state if machine stays shorter than x ms not in idle func (avg) [40].);
+
+static unsigned int bm_promote_ms = 30;
+module_param(bm_promote_ms, uint, 0644);
+MODULE_PARM_DESC(bm_promote_ms, Promote to lower state if avg bm is less than x ms [30].);
+
+//#define DEBUG 1
+#ifdef DEBUG
+#define myPrintk(string, args...) printk(KERN_INFO string, ##args);
+#else
+#define myPrintk(string, args...) {};
+#endif
+
+
/*
* bm_history -- bit-mask with a bit per jiffy of bus-master activity
* 1000 HZ: 0x: 32 jiffies = 32ms
@@ -162,6 +178,88 @@
return;
}
+u16 calc_average (u64 last_measures){
+ int x;
+ u16 ret = 0;
+ for (x = 0; x sizeof(u64)*8; x+=16){
+
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi,
On Tue, Apr 19, 2005 at 04:56:56PM +0200, Thomas Renninger wrote:
If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
three control values (averages of the last 4 measures):
a) idle_ms - if machine was active for longer than this
value (avg), the machine is assumed to not be idle
and C1 will be triggered.
b) bm_promote_ms - if the avg bus master activity is below
this threshold, C2 is invoked.
c) sleep_avg (no module param) - the average sleep time of the
last four C2 (or higher) invokations.
If a and b does not apply, a C-state will be searched that has
the highest latency, but still has a latency below the latest
C2 (or higher) sleeping time and average sleeping time value.
I think that we don't need this complication:
+//#define DEBUG 1
+#ifdef DEBUG
+#define myPrintk(string, args...) printk(KERN_INFO string, ##args);
+#else
+#define myPrintk(string, args...) {};
+#endif
Please don't do that... dprintk() is much more common. Also, then don't
comment dprintk() out below in the patch...
if (pr-flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr-power.bm_check_timestamp;
-
- if (diff 32)
- diff = 32;
-
- while (diff) {
- /* if we didn't get called, assume there was busmaster
activity */
- diff--;
- if (diff)
- pr-power.bm_activity |= 0x1;
- pr-power.bm_activity = 1;
- }
All we need to do is to update the diff. Without dynamic ticks, if the
idle loop didn't get called each jiffy, it was a big hint that there was so
much activity in between, and if there is activity, there is most likely
also bus master activity, or at least more work to do, so interrupt activity
is likely. Therefore we assume there was bm_activity even if there was none.
Now, we do know the jiffy value when we started sleeping. If we use
ticks_elapsed(t1, t2), convert it to jiffies, and do
diff = jiffies - (pr-power.bm_check_timestamp + last_sleep_jiffies);
it should work. I wrote a quick patch to do that, but it locked up my
notebook, so it is most likely broken; hopefully I'll find some time to debug
it, if somebody does it earlier, that'd be great, though.
Thanks,
Dominik
Only assume busmaster activity on non-idle ticks if we didn't sleep until
that jiffy. Needed for dyn-idle.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
--- linux/drivers/acpi/processor_idle.c.original2005-04-10
20:04:12.0 +0200
+++ linux/drivers/acpi/processor_idle.c 2005-04-10 20:14:33.0 +0200
@@ -120,6 +120,14 @@
return ((0x - t1) + t2);
}
+static inline u32
+ticks_to_jiffies (u32 pm_ticks)
+{
+ pm_ticks *= 286;
+ pm_ticks = (pm_ticks 10);
+ return (pm_ticks / (USEC_PER_SEC / HZ));
+}
+
static void
acpi_processor_power_activate (
@@ -169,7 +177,7 @@
struct acpi_processor_cx *cx = NULL;
struct acpi_processor_cx *next_state = NULL;
int sleep_ticks = 0;
- u32 t1, t2 = 0;
+ u32 t1, t2, td = 0;
pr = processors[_smp_processor_id()];
if (!pr)
@@ -201,11 +209,13 @@
* for demotion.
*/
if (pr-flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr-power.bm_check_timestamp;
+ u32 bm_status = 0;
+ longdiff = jiffies - pr-power.bm_check_timestamp;
if (diff 32)
diff = 32;
+ else if (diff 0)
+ diff = 0;
while (diff) {
/* if we didn't get called, assume there was busmaster
activity */
@@ -293,7 +303,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx-latency_ticks -
C2_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx-latency_ticks - C2_OVERHEAD;
+ pr-power.bm_check_timestamp += ticks_to_jiffies(td);
break;
case ACPI_STATE_C3:
@@ -312,7 +324,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx-latency_ticks -
C3_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx-latency_ticks - C3_OVERHEAD;
+ pr-power.bm_check_timestamp += ticks_to_jiffies(td);
break;
default:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Reducing the CC'd people a bit ...
Dominik Brodowski wrote:
Hi,
On Tue, Apr 19, 2005 at 04:56:56PM +0200, Thomas Renninger wrote:
If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
three control values (averages of the last 4 measures):
a) idle_ms - if machine was active for longer than this
value (avg), the machine is assumed to not be idle
and C1 will be triggered.
b) bm_promote_ms - if the avg bus master activity is below
this threshold, C2 is invoked.
c) sleep_avg (no module param) - the average sleep time of the
last four C2 (or higher) invokations.
If a and b does not apply, a C-state will be searched that has
the highest latency, but still has a latency below the latest
C2 (or higher) sleeping time and average sleeping time value.
I think that we don't need this complication:
+//#define DEBUG 1
+#ifdef DEBUG
+#define myPrintk(string, args...) printk(KERN_INFO string, ##args);
+#else
+#define myPrintk(string, args...) {};
+#endif
Please don't do that... dprintk() is much more common. Also, then don't
comment dprintk() out below in the patch...
Ok, this patch is far from perfect, I am happy that it finally runs that nice on
my machine.
if (pr-flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr-power.bm_check_timestamp;
-
- if (diff 32)
- diff = 32;
-
- while (diff) {
- /* if we didn't get called, assume there was busmaster
activity */
- diff--;
- if (diff)
- pr-power.bm_activity |= 0x1;
- pr-power.bm_activity = 1;
- }
All we need to do is to update the diff. Without dynamic ticks, if the
idle loop didn't get called each jiffy, it was a big hint that there was so
much activity in between, and if there is activity, there is most likely
also bus master activity, or at least more work to do, so interrupt activity
is likely. Therefore we assume there was bm_activity even if there was none.
If I understand this right you want at least wait 32 (or whatever value) ms if
there was bm activity,
before it is allowed to trigger C3/C4?
I think the problem is (at least I made the experience with this particular
machine)
that bm activity comes very often and regularly (each 30-150ms?).
I think the approach to directly adjust the latency to a deeper sleep state if
the
average bus master and OS activity is low is very efficient.
Because I don't consider whether there was bm_activity the last ms, I only
consider the average, it seems to happen that I try to trigger
C3/C4 when there is just something copied and some bm active ?!? Therefore, it
seems to happen
that triggering C3/C4 fails (sleep_ticks 0). The value of failures is getting
smaller if I increase
the limit for average bm activity before triggering C3/C4 (bm_promote_ms must
be smaller than average bm activity),
but it never will reach zero.
The patch is useless if these failures end up in system freezes on other
machines...
AFAIK there were a lot of freeze problems with C-states? Don't know, it works
here.
The problem with the old approach is, that after (doesn't matter C1-Cx) sleep
and dyn_idle_tick,
the chance to wake up because of bm activity is very likely.
You enter idle() again - there was bm_activity - C2. Wake up after e.g. 50ms,
because
of bm_activity again (bm_sts bit set) - stay in C2, wake up after 40ms - bm
activity...
You only have the chance to get into deeper states if the sleeps are
interrupted by an interrupt, not bm activity.
I also thought about only reprogram timer if C1/C2 was successful x times and
no bm activity was detected,
same mechanism as now, then only reprogram timer (dyn tick) for deeper sleep
states - like that, you
still can be sure the last x ms was no bm activity bit set before going to deep
sleeps.
But I don't know how to do it.
Now, we do know the jiffy value when we started sleeping. If we use
ticks_elapsed(t1, t2), convert it to jiffies, and do
diff = jiffies - (pr-power.bm_check_timestamp + last_sleep_jiffies);
it should work. I wrote a quick patch to do that, but it locked up my
notebook, so it is most likely broken; hopefully I'll find some time to debug
it, if somebody does it earlier, that'd be great, though.
Thanks,
Dominik
Only assume busmaster activity on non-idle ticks if we didn't sleep until
that jiffy. Needed for dyn-idle.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
--- linux/drivers/acpi/processor_idle.c.original 2005-04-10
20:04:12.0 +0200
+++ linux/drivers/acpi/processor_idle.c 2005-04-10 20:14:33.0
+0200
@@ -120,6 +120,14 @@
return ((0x - t1) + t2);
}
+static inline u32
+ticks_to_jiffies (u32 pm_ticks)
+{
+ pm_ticks *= 286;
+ pm_ticks = (pm_ticks 10);
+ return (pm_ticks / (USEC_PER_SEC /
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi! The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power states. The machine run at 2.00 GHz all the time. .. _passing bm_history=0x (default) to processor module:_ Average current the last 470 seconds: *1986mA* (also measured better values ~1800, does battery level play a role?!?) Probably yes. If voltage changes, 2000mA means different ammount of power. (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) _passing bm_history=0xFF to processor module:_ Average current the last 190 seconds: *1757mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) (Usage count could be bogus, as some invokations could not succeed if bm has currently been active). Ok. idle_ms == 100, bm_promote_bs == 30 Average current the last 80 seconds: *1466mA* (cmp. ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) Very nice indeed. That seems like ~5W saved, right? That might give you one more hour of battery life Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Sat, Apr 09, 2005 at 11:56:08AM +0200, Pavel Machek wrote: > Hi! > > > > > > I think I have an idea on what's going on; Your system does not wake > > > > > to > > > > > APIC interrupt, and the system timer updates time only on other > > > > > interrupts. > > > > > I'm experiencing the same on a loaner ThinkPad T30. > > > > > > > > > > I'll try to do another patch today. Meanwhile it now should work > > > > > without lapic in cmdline. > > > > > > > > Following is an updated patch. Anybody having trouble, please try > > > > disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > > > > > > > > I'm hoping this might work on Pavel's machine too? > > > > > > The "volume hang" was explained: I was using CPU frequency scaling, it > > > probably did not like that. After disabling CPU frequency scaling, it > > > seems to work ok: > > > > OK, good. I assume this was the same machine that did not work with > > any of the earlier patches > > I did testing on that machine today, and yes it works okay if I disable the > NO_IDLE_HZ_USE_APIC (or how is it called) option. Time problems are gone. That's great! Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! > > > > I think I have an idea on what's going on; Your system does not wake to > > > > APIC interrupt, and the system timer updates time only on other > > > > interrupts. > > > > I'm experiencing the same on a loaner ThinkPad T30. > > > > > > > > I'll try to do another patch today. Meanwhile it now should work > > > > without lapic in cmdline. > > > > > > Following is an updated patch. Anybody having trouble, please try > > > disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > > > > > > I'm hoping this might work on Pavel's machine too? > > > > The "volume hang" was explained: I was using CPU frequency scaling, it > > probably did not like that. After disabling CPU frequency scaling, it > > seems to work ok: > > OK, good. I assume this was the same machine that did not work with > any of the earlier patches I did testing on that machine today, and yes it works okay if I disable the NO_IDLE_HZ_USE_APIC (or how is it called) option. Time problems are gone. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches I did testing on that machine today, and yes it works okay if I disable the NO_IDLE_HZ_USE_APIC (or how is it called) option. Time problems are gone. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Sat, Apr 09, 2005 at 11:56:08AM +0200, Pavel Machek wrote: Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches I did testing on that machine today, and yes it works okay if I disable the NO_IDLE_HZ_USE_APIC (or how is it called) option. Time problems are gone. That's great! Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Fri, Apr 08, 2005 at 02:58:50PM +0200, Thomas Renninger wrote: > Tony Lindgren wrote: > > * Thomas Renninger <[EMAIL PROTECTED]> [050408 04:34]: > >>Here are some figures about idle/C-states: > >> > >>Passing bm_history=0xF to processor module makes it going into C3 and > >>deeper. > >>Passing lower values, deeper states are reached more often, but system > >>could freeze: > > > > Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? > > > It's an ACPI issue. OK > As far as I understand: If there has been bus master activity in the last > xx(~30?!?) ms, C3 and deeper sleep states must not be triggered. > If running into it, the system just freezes without any further output > or response. OK > >>Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) > > ... > >>Total switches between C-states: 20205 > >>Switches between C-states per second: 1063 per second > >> > >>Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: > > ... > >>Total switches between C-states: 4659 > >>Switches between C-states per second: 65 per second > > > > The reduction in C state changes should produce some power savings, > > assuming the C states do something... > > > I heard on this machine battery lasts half an hour longer since > C4 state is used, hopefully we can get some more minutes by using it > more often and longer ... Yeah, it would be interesting to know how much of a difference it makes. > >>I buffer C-state times in an array and write them to /dev/cstX. > >>From there I calc the stats from userspace. > >> > >>Tony: If you like I can send you the patch and dump prog for > >>http://www.muru.com/linux/dyntick/ ? > > > > Yeah, that would nice to have! > > -> I'll send you privately. OK > >>I try to find a better algorithm (directly adjust slept time to > >>C-state latency or something) for NO_IDLE_HZ (hints are very welcome) > >>and try to come up with new figures soon. > > > > I suggest we modify idle so we can call it with the estimated sleep > > length in usecs. Then the idle loop can directly decide when to go to > > C2 or C3 depening on the estimated sleep length. > > The sleep time history could be enough? Well we already know when the next timer interrupt is scheduled to happen, so make use of that information would make the state selection easy. And we should probably at some point also account for the wake-up latency so we can program the timer a bit early depending on the sleep state. > I don't know how to calc C1 state sleep time (from > drivers/acpi/processor_idle.c): > /* > * TBD: Can't get time duration while in C1, as resumes >* go to an ISR rather than here. Need to instrument >* base interrupt handler. >*/ > > It probably would help to go to deeper states faster. Yes, we should be able to go directly to deeper states with the next timer interrupt value. > Whatabout reprogramming timer interrupt for C1 (latency==0), so that it comes > out after e.g. 1 ms again. > If it really stayed sleeping for 1ms, 5 times, the machine is really idle and > deeper > states are adjusted after sleep time and C-state latency... > (Or only disable timer interrupt after C1 slept long enough X times?) I'm not sure if I follow this one... But if we know the next timer interrupt is 500ms away, we should go directly to C3/C4, and no other calculations should be needed. Regards, Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Fri, Apr 08, 2005 at 03:42:59PM -0600, Frank Sorenson wrote: > Tony Lindgren wrote: > > > > Then you might as well run timetest from same location too to make > > sure your clock keeps correct time. > > Seems to be going up when under load, and down when idle, so I suppose > it's working :) The clock is only a little jittery, but not more than > I'd expect across the network, so it looks like it's keeping time okay. Good. > Would it be possible to determine whether the system will wake to the > APIC interrupt at system boot, rather than hardcoded in the config? > After you explained the problem, I noticed that creating my own > interrupts (holding down a key on the keyboard for example) kept the > system moving and not slow. For example, something like this (sorry, I > don't know the code well enough yet to attempt to code it myself): > > set the APIC timer to fire in X > set another timer/interrupt to fire in 2X > wait for the interrupt > if (time_elapsed >= 2X) disable the APIC timer > else APIC timer should work > > Or, determine which timer woke us up, etc. Yeah, I was thinking that too. But maybe there's some way of stopping PIT interrupts while keeping APIC timer interrupts running on all chips. It seems to work OK on my P3 boxes, but seems to fail on newer machines. BTW, stopping PIT interrupts (like the HRT VST patch does) seems to kill APIC timer interrupts too, the same way as reprogamming PIT does. Or maybe there's something else that needs to be done to get APIC interrupts going after PIT interrupts are disabled. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Fri, Apr 08, 2005 at 03:42:59PM -0600, Frank Sorenson wrote: Tony Lindgren wrote: Then you might as well run timetest from same location too to make sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Good. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed = 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Yeah, I was thinking that too. But maybe there's some way of stopping PIT interrupts while keeping APIC timer interrupts running on all chips. It seems to work OK on my P3 boxes, but seems to fail on newer machines. BTW, stopping PIT interrupts (like the HRT VST patch does) seems to kill APIC timer interrupts too, the same way as reprogamming PIT does. Or maybe there's something else that needs to be done to get APIC interrupts going after PIT interrupts are disabled. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
On Fri, Apr 08, 2005 at 02:58:50PM +0200, Thomas Renninger wrote: Tony Lindgren wrote: * Thomas Renninger [EMAIL PROTECTED] [050408 04:34]: Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? It's an ACPI issue. OK As far as I understand: If there has been bus master activity in the last xx(~30?!?) ms, C3 and deeper sleep states must not be triggered. If running into it, the system just freezes without any further output or response. OK Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) ... Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: ... Total switches between C-states: 4659 Switches between C-states per second: 65 per second The reduction in C state changes should produce some power savings, assuming the C states do something... I heard on this machine battery lasts half an hour longer since C4 state is used, hopefully we can get some more minutes by using it more often and longer ... Yeah, it would be interesting to know how much of a difference it makes. I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? Yeah, that would nice to have! - I'll send you privately. OK I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. I suggest we modify idle so we can call it with the estimated sleep length in usecs. Then the idle loop can directly decide when to go to C2 or C3 depening on the estimated sleep length. The sleep time history could be enough? Well we already know when the next timer interrupt is scheduled to happen, so make use of that information would make the state selection easy. And we should probably at some point also account for the wake-up latency so we can program the timer a bit early depending on the sleep state. I don't know how to calc C1 state sleep time (from drivers/acpi/processor_idle.c): /* * TBD: Can't get time duration while in C1, as resumes * go to an ISR rather than here. Need to instrument * base interrupt handler. */ It probably would help to go to deeper states faster. Yes, we should be able to go directly to deeper states with the next timer interrupt value. Whatabout reprogramming timer interrupt for C1 (latency==0), so that it comes out after e.g. 1 ms again. If it really stayed sleeping for 1ms, 5 times, the machine is really idle and deeper states are adjusted after sleep time and C-state latency... (Or only disable timer interrupt after C1 slept long enough X times?) I'm not sure if I follow this one... But if we know the next timer interrupt is 500ms away, we should go directly to C3/C4, and no other calculations should be needed. Regards, Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: > * Frank Sorenson <[EMAIL PROTECTED]> [050408 01:49]: >>This updated patch seems to work just fine on my machine with lapic on >>the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. >> >>Also, you were correct that removing lapic from the cmdline allowed the >>previous version to run at full speed. > > > Cool. > > >>Now, how can I tell if the patch is doing its thing? What should I be >>seeing? :) > > > Download pmstats from http://www.muru.com/linux/dyntick/, you may > need to edit it a bit for correct ACPI battery values. But it should > show you HZ during idle and load. I believe idle still does not go > to ACPI C3 with dyn-tick though... > > Then you might as well run timetest from same location too to make > sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed >= 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVvriaI0dwg4A47wRAhhyAJ928wgPEY/9X4KmyJcsaJ+WZk0XRQCfTfcj x3yKiwYOhMac/SQ7El9N0q0= =2QVB -END PGP SIGNATURE- - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Tony Lindgren wrote: > * Thomas Renninger <[EMAIL PROTECTED]> [050408 04:34]: >>Here are some figures about idle/C-states: >> >>Passing bm_history=0xF to processor module makes it going into C3 and deeper. >>Passing lower values, deeper states are reached more often, but system could >>freeze: > > Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? > It's an ACPI issue. As far as I understand: If there has been bus master activity in the last xx(~30?!?) ms, C3 and deeper sleep states must not be triggered. If running into it, the system just freezes without any further output or response. >>Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) > ... >>Total switches between C-states: 20205 >>Switches between C-states per second: 1063 per second >> >>Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: > ... >>Total switches between C-states: 4659 >>Switches between C-states per second: 65 per second > > The reduction in C state changes should produce some power savings, > assuming the C states do something... > I heard on this machine battery lasts half an hour longer since C4 state is used, hopefully we can get some more minutes by using it more often and longer ... >>I buffer C-state times in an array and write them to /dev/cstX. >>From there I calc the stats from userspace. >> >>Tony: If you like I can send you the patch and dump prog for >>http://www.muru.com/linux/dyntick/ ? > > Yeah, that would nice to have! -> I'll send you privately. > >>I try to find a better algorithm (directly adjust slept time to >>C-state latency or something) for NO_IDLE_HZ (hints are very welcome) >>and try to come up with new figures soon. > > I suggest we modify idle so we can call it with the estimated sleep > length in usecs. Then the idle loop can directly decide when to go to > C2 or C3 depening on the estimated sleep length. The sleep time history could be enough? I don't know how to calc C1 state sleep time (from drivers/acpi/processor_idle.c): /* * TBD: Can't get time duration while in C1, as resumes * go to an ISR rather than here. Need to instrument * base interrupt handler. */ It probably would help to go to deeper states faster. Whatabout reprogramming timer interrupt for C1 (latency==0), so that it comes out after e.g. 1 ms again. If it really stayed sleeping for 1ms, 5 times, the machine is really idle and deeper states are adjusted after sleep time and C-state latency... (Or only disable timer interrupt after C1 slept long enough X times?) Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! > > > > I think I have an idea on what's going on; Your system does not wake to > > > > APIC interrupt, and the system timer updates time only on other > > > > interrupts. > > > > I'm experiencing the same on a loaner ThinkPad T30. > > > > > > > > I'll try to do another patch today. Meanwhile it now should work > > > > without lapic in cmdline. > > > > > > Following is an updated patch. Anybody having trouble, please try > > > disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > > > > > > I'm hoping this might work on Pavel's machine too? > > > > The "volume hang" was explained: I was using CPU frequency scaling, it > > probably did not like that. After disabling CPU frequency scaling, it > > seems to work ok: > > OK, good. I assume this was the same machine that did not work with > any of the earlier patches? I do not have *that* machine near me just now, but I'll try it. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Thomas Renninger <[EMAIL PROTECTED]> [050408 04:34]: > > Here are some figures about idle/C-states: > > Passing bm_history=0xF to processor module makes it going into C3 and deeper. > Passing lower values, deeper states are reached more often, but system could > freeze: Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? > Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) ... > Total switches between C-states: 20205 > Switches between C-states per second: 1063 per second > > Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: ... > Total switches between C-states: 4659 > Switches between C-states per second: 65 per second The reduction in C state changes should produce some power savings, assuming the C states do something... > I buffer C-state times in an array and write them to /dev/cstX. > From there I calc the stats from userspace. > > Tony: If you like I can send you the patch and dump prog for > http://www.muru.com/linux/dyntick/ ? Yeah, that would nice to have! > I try to find a better algorithm (directly adjust slept time to > C-state latency or something) for NO_IDLE_HZ (hints are very welcome) > and try to come up with new figures soon. I suggest we modify idle so we can call it with the estimated sleep length in usecs. Then the idle loop can directly decide when to go to C2 or C3 depening on the estimated sleep length. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Frank Sorenson wrote: > Tony Lindgren wrote: > | * Tony Lindgren <[EMAIL PROTECTED]> [050407 23:28]: > | > |>I think I have an idea on what's going on; Your system does not wake to > |>APIC interrupt, and the system timer updates time only on other > interrupts. > |>I'm experiencing the same on a loaner ThinkPad T30. > |> > |>I'll try to do another patch today. Meanwhile it now should work > |>without lapic in cmdline. > | > | > | Following is an updated patch. Anybody having trouble, please try > | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > | > | I'm hoping this might work on Pavel's machine too? > | > | Tony > > This updated patch seems to work just fine on my machine with lapic on > the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. > > Also, you were correct that removing lapic from the cmdline allowed the > previous version to run at full speed. > > Now, how can I tell if the patch is doing its thing? What should I be > seeing? :) > > Functionally, it looks like it's working. There were a number of > compiler warnings you might wish to fix before calling it good. Such as > "initialization from incompatible pointer type" several times in > dyn-tick-timer.c and a "too many arguments for format" in > dyn_tick_late_init. > Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: bm_activity=0x4 bus master activity: fefd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[7183] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0515] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0330] bm_activity=0x1 bus master activity: 7ffd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[5495] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0537] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0472] Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):145 Usage:20205 Failures: 0 Maximum(us): 1967 Average(us): 7 Sleep C2 state: Total(ms):19306 Usage:20074 Failures: 0 Maximum(us): 1275(-> strange max should be 1000us) Average(us): 961 Sleep C3 state: Total(ms):34 Usage:131 Failures: 0 Maximum(us): 984 Average(us): 259 Measures based on ACPI PM timer reads Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Total measure time (s): 19 Total measure time (based on starting measures) (s): 20 Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):81 Usage:4659 Failures: 0 Maximum(us): 1608 Average(us): 17 Sleep C2 state: Total(ms):71108 Usage:4241 Failures: 0 Maximum(us): 49921 Average(us): 16766 Sleep C3 state: Total(ms):219 Usage:167 Failures: 0 Maximum(us): 28296 Average(us): 1311 Sleep C4 state: Total(ms):374 Usage:251 Failures: 0 Maximum(us): 18870 Average(us): 1490 Measures based on ACPI PM timer reads Total switches between C-states: 4659 Switches between C-states per second: 65 per second Total measure time (s): 71 Total measure time (based on starting measures) (s): 75 I buffer C-state times in an array and write them to /dev/cstX. >From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Pavel Machek <[EMAIL PROTECTED]> [050408 03:30]: > Hi! > > > > I think I have an idea on what's going on; Your system does not wake to > > > APIC interrupt, and the system timer updates time only on other > > > interrupts. > > > I'm experiencing the same on a loaner ThinkPad T30. > > > > > > I'll try to do another patch today. Meanwhile it now should work > > > without lapic in cmdline. > > > > Following is an updated patch. Anybody having trouble, please try > > disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > > > > I'm hoping this might work on Pavel's machine too? > > The "volume hang" was explained: I was using CPU frequency scaling, it > probably did not like that. After disabling CPU frequency scaling, it > seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches? Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! > > I think I have an idea on what's going on; Your system does not wake to > > APIC interrupt, and the system timer updates time only on other interrupts. > > I'm experiencing the same on a loaner ThinkPad T30. > > > > I'll try to do another patch today. Meanwhile it now should work > > without lapic in cmdline. > > Following is an updated patch. Anybody having trouble, please try > disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > > I'm hoping this might work on Pavel's machine too? The "volume hang" was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: Pavel [EMAIL PROTECTED]:~$ cat /proc/interrupts ; sleep 1 ; cat /proc/interrupts CPU0 0: 33288 XT-PIC timer 1: 1021 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94036 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3941 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5119 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 CPU0 0: 33568 XT-PIC timer 1: 1022 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94323 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3951 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5192 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 [EMAIL PROTECTED]:~$ -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Frank Sorenson <[EMAIL PROTECTED]> [050408 01:49]: > Tony Lindgren wrote: > | * Tony Lindgren <[EMAIL PROTECTED]> [050407 23:28]: > | > |>I think I have an idea on what's going on; Your system does not wake to > |>APIC interrupt, and the system timer updates time only on other > interrupts. > |>I'm experiencing the same on a loaner ThinkPad T30. > |> > |>I'll try to do another patch today. Meanwhile it now should work > |>without lapic in cmdline. > | > | > | Following is an updated patch. Anybody having trouble, please try > | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. > | > | I'm hoping this might work on Pavel's machine too? > | > | Tony > > This updated patch seems to work just fine on my machine with lapic on > the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. > > Also, you were correct that removing lapic from the cmdline allowed the > previous version to run at full speed. Cool. > Now, how can I tell if the patch is doing its thing? What should I be > seeing? :) Download pmstats from http://www.muru.com/linux/dyntick/, you may need to edit it a bit for correct ACPI battery values. But it should show you HZ during idle and load. I believe idle still does not go to ACPI C3 with dyn-tick though... Then you might as well run timetest from same location too to make sure your clock keeps correct time. > Functionally, it looks like it's working. There were a number of > compiler warnings you might wish to fix before calling it good. Such as > "initialization from incompatible pointer type" several times in > dyn-tick-timer.c and a "too many arguments for format" in > dyn_tick_late_init. Yeah, I'll fix those... Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: | * Tony Lindgren <[EMAIL PROTECTED]> [050407 23:28]: | |>I think I have an idea on what's going on; Your system does not wake to |>APIC interrupt, and the system timer updates time only on other interrupts. |>I'm experiencing the same on a loaner ThinkPad T30. |> |>I'll try to do another patch today. Meanwhile it now should work |>without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as "initialization from incompatible pointer type" several times in dyn-tick-timer.c and a "too many arguments for format" in dyn_tick_late_init. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVkWDaI0dwg4A47wRAgzOAKCHcx8p59ZbihYtZJ84p62v2rMauQCfUuzz D7O98hHvjtTa/CvFHHtJe4c= =G2I/ -END PGP SIGNATURE- - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Tony Lindgren <[EMAIL PROTECTED]> [050407 23:28]:
>
> I think I have an idea on what's going on; Your system does not wake to
> APIC interrupt, and the system timer updates time only on other interrupts.
> I'm experiencing the same on a loaner ThinkPad T30.
>
> I'll try to do another patch today. Meanwhile it now should work
> without lapic in cmdline.
Following is an updated patch. Anybody having trouble, please try
disabling CONFIG_DYN_TICK_USE_APIC Kconfig option.
I'm hoping this might work on Pavel's machine too?
Tony
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
@@ -460,6 +460,26 @@
bool "Provide RTC interrupt"
depends on HPET_TIMER && RTC=y
+config NO_IDLE_HZ
+ bool "Dynamic Tick Timer - Skip timer ticks during idle"
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
+config DYN_TICK_USE_APIC
+ bool "Use APIC timer instead of PIT timer"
+ help
+ This option enables using APIC timer interrupt if your hardware
+ supports it. APIC timer allows longer sleep periods compared
+ to PIT timer. Note that on some hardware disabling PIT timer
+ also disables APIC timer interrupts, and system won't run
+ properly. Symptoms include slow system boot, and time running
+ slow. If unsure, don't enable this option.
+
config SMP
bool "Symmetric multi-processing support"
---help---
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
@@ -30,6 +30,7 @@
obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_HPET_TIMER) += time_hpet.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -909,6 +910,8 @@
#define APIC_DIVISOR 16
+static u32 apic_timer_val;
+
static void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -927,7 +930,15 @@
& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
- apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+ apic_timer_val = clocks/APIC_DIVISOR;
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /* Local APIC timer is 24-bit */
+ if (apic_timer_val)
+ dyn_tick->max_skip = 0xff / apic_timer_val;
+#endif
+
+ apic_write_around(APIC_TMICT, apic_timer_val);
}
static void __init setup_APIC_timer(unsigned int clocks)
@@ -1040,6 +1051,13 @@
*/
setup_APIC_timer(calibration_result);
+#ifdef CONFIG_NO_IDLE_HZ
+ if (calibration_result)
+ dyn_tick->state |= DYN_TICK_USE_APIC;
+ else
+ printk(KERN_INFO "dyn-tick: Cannot use local APIC\n");
+#endif
+
local_irq_enable();
}
@@ -1068,6 +1086,18 @@
}
}
+#if defined(CONFIG_NO_IDLE_HZ)
+void reprogram_apic_timer(unsigned int count)
+{
+ unsigned long flags;
+
+ count *= apic_timer_val;
+ local_irq_save(flags);
+ apic_write_around(APIC_TMICT, count);
+ local_irq_restore(flags);
+}
+#endif
+
/*
* the frequency of the profiling timer can be changed
* by writing a multiplier value into /proc/profile.
@@ -1160,6 +1190,7 @@
fastcall void smp_apic_timer_interrupt(struct pt_regs *regs)
{
+ unsigned long seq;
int cpu = smp_processor_id();
/*
@@ -1178,6 +1209,23 @@
* interrupt lock, which is the WrongThing (tm) to do.
*/
irq_enter();
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /*
+* Check if we need to wake up PIT interrupt handler.
+* Otherwise just wake up local APIC timer.
+*/
+ do {
+ seq = read_seqbegin(_lock);
+ if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+ if (dyn_tick->skip_cpu == cpu && dyn_tick->skip >
DYN_TICK_MIN_SKIP)
+ dyn_tick->interrupt(99, NULL, regs);
+ else
+ reprogram_apic_timer(1);
+ }
+ } while (read_seqretry(_lock, seq));
+#endif
+
Re: [PATCH] Updated: Dynamic Tick version 050408-1
* Tony Lindgren [EMAIL PROTECTED] [050407 23:28]:
I think I have an idea on what's going on; Your system does not wake to
APIC interrupt, and the system timer updates time only on other interrupts.
I'm experiencing the same on a loaner ThinkPad T30.
I'll try to do another patch today. Meanwhile it now should work
without lapic in cmdline.
Following is an updated patch. Anybody having trouble, please try
disabling CONFIG_DYN_TICK_USE_APIC Kconfig option.
I'm hoping this might work on Pavel's machine too?
Tony
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/Kconfig 2005-04-08 00:43:41 -07:00
@@ -460,6 +460,26 @@
bool Provide RTC interrupt
depends on HPET_TIMER RTC=y
+config NO_IDLE_HZ
+ bool Dynamic Tick Timer - Skip timer ticks during idle
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
+config DYN_TICK_USE_APIC
+ bool Use APIC timer instead of PIT timer
+ help
+ This option enables using APIC timer interrupt if your hardware
+ supports it. APIC timer allows longer sleep periods compared
+ to PIT timer. Note that on some hardware disabling PIT timer
+ also disables APIC timer interrupts, and system won't run
+ properly. Symptoms include slow system boot, and time running
+ slow. If unsure, don't enable this option.
+
config SMP
bool Symmetric multi-processing support
---help---
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/Makefile 2005-04-08 00:43:41 -07:00
@@ -30,6 +30,7 @@
obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_HPET_TIMER) += time_hpet.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
+++ b/arch/i386/kernel/apic.c 2005-04-08 00:43:41 -07:00
@@ -26,6 +26,7 @@
#include linux/mc146818rtc.h
#include linux/kernel_stat.h
#include linux/sysdev.h
+#include linux/dyn-tick-timer.h
#include asm/atomic.h
#include asm/smp.h
@@ -909,6 +910,8 @@
#define APIC_DIVISOR 16
+static u32 apic_timer_val;
+
static void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -927,7 +930,15 @@
~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
- apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+ apic_timer_val = clocks/APIC_DIVISOR;
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /* Local APIC timer is 24-bit */
+ if (apic_timer_val)
+ dyn_tick-max_skip = 0xff / apic_timer_val;
+#endif
+
+ apic_write_around(APIC_TMICT, apic_timer_val);
}
static void __init setup_APIC_timer(unsigned int clocks)
@@ -1040,6 +1051,13 @@
*/
setup_APIC_timer(calibration_result);
+#ifdef CONFIG_NO_IDLE_HZ
+ if (calibration_result)
+ dyn_tick-state |= DYN_TICK_USE_APIC;
+ else
+ printk(KERN_INFO dyn-tick: Cannot use local APIC\n);
+#endif
+
local_irq_enable();
}
@@ -1068,6 +1086,18 @@
}
}
+#if defined(CONFIG_NO_IDLE_HZ)
+void reprogram_apic_timer(unsigned int count)
+{
+ unsigned long flags;
+
+ count *= apic_timer_val;
+ local_irq_save(flags);
+ apic_write_around(APIC_TMICT, count);
+ local_irq_restore(flags);
+}
+#endif
+
/*
* the frequency of the profiling timer can be changed
* by writing a multiplier value into /proc/profile.
@@ -1160,6 +1190,7 @@
fastcall void smp_apic_timer_interrupt(struct pt_regs *regs)
{
+ unsigned long seq;
int cpu = smp_processor_id();
/*
@@ -1178,6 +1209,23 @@
* interrupt lock, which is the WrongThing (tm) to do.
*/
irq_enter();
+
+#ifdef CONFIG_NO_IDLE_HZ
+ /*
+* Check if we need to wake up PIT interrupt handler.
+* Otherwise just wake up local APIC timer.
+*/
+ do {
+ seq = read_seqbegin(xtime_lock);
+ if (dyn_tick-state (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+ if (dyn_tick-skip_cpu == cpu dyn_tick-skip
DYN_TICK_MIN_SKIP)
+ dyn_tick-interrupt(99, NULL, regs);
+ else
+ reprogram_apic_timer(1);
+
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVkWDaI0dwg4A47wRAgzOAKCHcx8p59ZbihYtZJ84p62v2rMauQCfUuzz D7O98hHvjtTa/CvFHHtJe4c= =G2I/ -END PGP SIGNATURE- - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Frank Sorenson [EMAIL PROTECTED] [050408 01:49]: Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Cool. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Download pmstats from http://www.muru.com/linux/dyntick/, you may need to edit it a bit for correct ACPI battery values. But it should show you HZ during idle and load. I believe idle still does not go to ACPI C3 with dyn-tick though... Then you might as well run timetest from same location too to make sure your clock keeps correct time. Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Yeah, I'll fix those... Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: Pavel [EMAIL PROTECTED]:~$ cat /proc/interrupts ; sleep 1 ; cat /proc/interrupts CPU0 0: 33288 XT-PIC timer 1: 1021 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94036 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3941 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5119 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 CPU0 0: 33568 XT-PIC timer 1: 1022 XT-PIC i8042 2: 0 XT-PIC cascade 9: 2 XT-PIC acpi 10: 94323 XT-PIC yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 11: 3951 XT-PIC Intel 82801DB-ICH4, eth0 12: 17 XT-PIC i8042 14: 5192 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 [EMAIL PROTECTED]:~$ -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Pavel Machek [EMAIL PROTECTED] [050408 03:30]: Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches? Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Frank Sorenson wrote: Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: bm_activity=0x4 bus master activity: fefd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[7183] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0515] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0330] bm_activity=0x1 bus master activity: 7ffd states: C1: type[C1] promotion[C2] demotion[--] latency[001] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[5495] C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[0537] C4: type[C3] promotion[--] demotion[C3] latency[185] usage[0472] Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):145 Usage:20205 Failures: 0 Maximum(us): 1967 Average(us): 7 Sleep C2 state: Total(ms):19306 Usage:20074 Failures: 0 Maximum(us): 1275(- strange max should be 1000us) Average(us): 961 Sleep C3 state: Total(ms):34 Usage:131 Failures: 0 Maximum(us): 984 Average(us): 259 Measures based on ACPI PM timer reads Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Total measure time (s): 19 Total measure time (based on starting measures) (s): 20 Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: (Don't trust the figures too much, there probably are little bugs...): Active C0/C1 state: Total(ms):81 Usage:4659 Failures: 0 Maximum(us): 1608 Average(us): 17 Sleep C2 state: Total(ms):71108 Usage:4241 Failures: 0 Maximum(us): 49921 Average(us): 16766 Sleep C3 state: Total(ms):219 Usage:167 Failures: 0 Maximum(us): 28296 Average(us): 1311 Sleep C4 state: Total(ms):374 Usage:251 Failures: 0 Maximum(us): 18870 Average(us): 1490 Measures based on ACPI PM timer reads Total switches between C-states: 4659 Switches between C-states per second: 65 per second Total measure time (s): 71 Total measure time (based on starting measures) (s): 75 I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1
* Thomas Renninger [EMAIL PROTECTED] [050408 04:34]: Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) ... Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: ... Total switches between C-states: 4659 Switches between C-states per second: 65 per second The reduction in C state changes should produce some power savings, assuming the C states do something... I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? Yeah, that would nice to have! I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. I suggest we modify idle so we can call it with the estimated sleep length in usecs. Then the idle loop can directly decide when to go to C2 or C3 depening on the estimated sleep length. Tony - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Hi! I think I have an idea on what's going on; Your system does not wake to APIC interrupt, and the system timer updates time only on other interrupts. I'm experiencing the same on a loaner ThinkPad T30. I'll try to do another patch today. Meanwhile it now should work without lapic in cmdline. Following is an updated patch. Anybody having trouble, please try disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. I'm hoping this might work on Pavel's machine too? The volume hang was explained: I was using CPU frequency scaling, it probably did not like that. After disabling CPU frequency scaling, it seems to work ok: OK, good. I assume this was the same machine that did not work with any of the earlier patches? I do not have *that* machine near me just now, but I'll try it. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [PATCH] Updated: Dynamic Tick version 050408-1
Tony Lindgren wrote: * Thomas Renninger [EMAIL PROTECTED] [050408 04:34]: Here are some figures about idle/C-states: Passing bm_history=0xF to processor module makes it going into C3 and deeper. Passing lower values, deeper states are reached more often, but system could freeze: Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick? It's an ACPI issue. As far as I understand: If there has been bus master activity in the last xx(~30?!?) ms, C3 and deeper sleep states must not be triggered. If running into it, the system just freezes without any further output or response. Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms) ... Total switches between C-states: 20205 Switches between C-states per second: 1063 per second Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000: ... Total switches between C-states: 4659 Switches between C-states per second: 65 per second The reduction in C state changes should produce some power savings, assuming the C states do something... I heard on this machine battery lasts half an hour longer since C4 state is used, hopefully we can get some more minutes by using it more often and longer ... I buffer C-state times in an array and write them to /dev/cstX. From there I calc the stats from userspace. Tony: If you like I can send you the patch and dump prog for http://www.muru.com/linux/dyntick/ ? Yeah, that would nice to have! - I'll send you privately. I try to find a better algorithm (directly adjust slept time to C-state latency or something) for NO_IDLE_HZ (hints are very welcome) and try to come up with new figures soon. I suggest we modify idle so we can call it with the estimated sleep length in usecs. Then the idle loop can directly decide when to go to C2 or C3 depening on the estimated sleep length. The sleep time history could be enough? I don't know how to calc C1 state sleep time (from drivers/acpi/processor_idle.c): /* * TBD: Can't get time duration while in C1, as resumes * go to an ISR rather than here. Need to instrument * base interrupt handler. */ It probably would help to go to deeper states faster. Whatabout reprogramming timer interrupt for C1 (latency==0), so that it comes out after e.g. 1 ms again. If it really stayed sleeping for 1ms, 5 times, the machine is really idle and deeper states are adjusted after sleep time and C-state latency... (Or only disable timer interrupt after C1 slept long enough X times?) Thomas - 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: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: * Frank Sorenson [EMAIL PROTECTED] [050408 01:49]: This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Cool. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Download pmstats from http://www.muru.com/linux/dyntick/, you may need to edit it a bit for correct ACPI battery values. But it should show you HZ during idle and load. I believe idle still does not go to ACPI C3 with dyn-tick though... Then you might as well run timetest from same location too to make sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed = 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVvriaI0dwg4A47wRAhhyAJ928wgPEY/9X4KmyJcsaJ+WZk0XRQCfTfcj x3yKiwYOhMac/SQ7El9N0q0= =2QVB -END PGP SIGNATURE- - 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/
