[lkml]   [2005]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures

> > > > 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?

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-20 14:17    [W:0.041 / U:5.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site