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/
