lkml.org 
[lkml]   [2008]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Active waiting with yield()
    On Tue, 18 Nov 2008, Arjan van de Ven wrote:

    > On Tue, 18 Nov 2008 09:34:16 -0500 (EST)
    > > So what are the reasons why you (and others) are against active
    > > waiting? All you are saying is that my reasons are wrong, but you
    > > haven't single example when active waiting causes trouble. If there
    > > is a workload when waiting 1ms-to-10ms with mdelay(1) on driver
    > > unload would cause discomfort to the user, describe it.
    > >
    >
    > mdelay()
    > * costs you quite a bit of power
    > * will cause your cpu to go to full speed
    > * makes it more likely that your fan goes on
    > * takes away CPU time from others who do want to run
    > - including the guy you are waiting for!
    > * if you do it with interrupts off you can even cause time skew
    > * adds 10 milliseconds of latency to the entire system, which is very
    > user noticable in a desktop environment (the threshold for that is
    > like 1 or 2 milliseconds total)

    msleep(1) should be better, mdelay doesn't give other processes a chance
    to run.

    > now there are some cases, mostly during error recovery or driver init
    > slowpaths where mdelay() can be justified, but "I'm too lazy to use a
    > waitqueue or other sleeping construct" is not one of them.

    That is exactly what my initial post was about. I agree that using polling
    on normal request processing is stupid, but I don't see why some people
    don't like msleep() it even in slow paths (such as driver unload).

    Mikulas

    > --
    > Arjan van de Ven Intel Open Source Technology Centre
    > For development, discussion and tips for power savings,
    > visit http://www.lesswatts.org
    >


    \
     
     \ /
      Last update: 2008-11-18 18:21    [W:2.713 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site