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

[Pavel Machek <pavel@suse.cz>]

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.