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

Pavel Machek
2005-04-20T12:08:46Z

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.