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/
