Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures

[Dominik Brodowski <linux@dominikbrodowski.net>]

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