LDD Chapter 7 says "In general, if you can tolerate longer delays than
requested, you should use schedule_timeout, msleep or ssleep.".
Following this rule, my kernel thread does:
while(1) msleep(1000);
Seconds later userspace guys start whining: "Your driver is evil,
loadavg is 1 and we did not even start our fancy application".
I say: "No, my code is perfectly fine, I followed LDD to the letter."
So the userspace guys head back to their cave, only to return after 5
hours of googling: "Hey, we know what you are doing. Your kernel thread
does uninterruptible sleeps. Wikipedia says, this means you are probably
waiting for disk activity."
Since I don't like having those whining userspace guys around I change
my code, reluctantly:
while(1) msleep_interruptible(1000);
Seconds later they say: "All hail great kernel hacker! You fixed it in
no time."
I appreciate their admiration, but still there are doubts in my mind: Is
this code really any better? Is the loadavg metric broken beyond repair?
Should I really avoid msleep, just to stop those userspace guys from
whining?
The truth must be out there ...
Cheers
Dirk
On 05/04/2011 02:11 PM, Eibach, Dirk wrote:
> while(1) msleep_interruptible(1000);
>
> I appreciate their admiration, but still there are doubts in my mind: Is
> this code really any better?
Try to send it a signal, it will eat 100% of CPU without sleeping.
> Is the loadavg metric broken beyond repair?
No, this is expected behaviour. Uninterruptible sleeps count as I/O load.
regards,
--
js
Eibach, Dirk wrote:
> while(1) msleep_interruptible(1000);
>
> Is this code really any better?
You should handle signals, probably by blocking any that you're not
interested in, and exiting on any fatal one.
Anyway, polling is bad; this code forces the CPU to wake up once
per second. What is your thread _actually_ waiting for?
(I guess it has more code than what you wrote?)
Regards,
Clemens
> > while(1) msleep_interruptible(1000);
> >
> > I appreciate their admiration, but still there are doubts
> in my mind:
> > Is this code really any better?
>
> Try to send it a signal, it will eat 100% of CPU without sleeping.
As I am a great kernel hacker, all signals are blocked ;)
> > Is the loadavg metric broken beyond repair?
>
> No, this is expected behaviour. Uninterruptible sleeps count
> as I/O load.
Ah, now we come to the point. Is there any practical reason behind this
or was it just an igenious invention to annoy those smug userspace
developers? I don't see any real world I/O load here.
> regards,
> --
> js
Cheers
Dirk
> > while(1) msleep_interruptible(1000);
> >
> > Is this code really any better?
>
> You should handle signals, probably by blocking any that
> you're not interested in, and exiting on any fatal one.
As I am a great kernel hacker, all signals are blocked ;)
> Anyway, polling is bad; this code forces the CPU to wake up
> once per second. What is your thread _actually_ waiting for?
> (I guess it has more code than what you wrote?)
Sure, polling is bad, but sometimes hard to avoid. My system is
monitoring some hardware it doesn't trust and looks once in a while if
it's still alive, just to make sure. As this is an embedded system
without any energy saving measures, waking up the CPU is not that much
of a problem.
Cheers
Dirk
--------------------------------------------------------------------------
Guntermann & Drunck GmbH Systementwicklung
Dortmunder Str. 4a
D-57234 Wilnsdorf - Germany
Tel: +49 (0) 27 39 / 89 01 - 100 Fax: +49 (0) 27 39 / 89 01 - 120
E-Mail: mailto:[email protected] Web: http://www.gdsys.de
--------------------------------------------------------------------------
Geschaeftsfuehrer:
Udo Guntermann - Martin Drunck - Reiner Ruelmann - Klaus Tocke
HRB 2884, Amtsgericht Siegen - WEEE-Reg.-Nr. DE30763240
USt.-Id.-Nr. DE 126575222 - Steuer-Nr. 342 / 5835 / 1041
--------------------------------------------------------------------------
DQS-zertifiziert nach ISO 9001:2008
--------------------------------------------------------------------------
Eibach, Dirk wrote:
> > Uninterruptible sleeps count as I/O load.
>
> Is there any practical reason behind this or was it just an igenious
> invention to annoy those smug userspace developers?
Historically, uninterruptible sleeps were the best way to detect I/O
load. Furthermore, a process that is doing I/O is very likely to
continue running soon, while other sleeps are more likely to indicate
that the process is waiting for some event to wake it up to begin doing
something, so this better predicts CPU load. Finally, a busy device is
likely to prevent other programs from running well, so it makes sense
to count this against the load.
msleep() is commonly used to handle device communication delays, which
is essentially the same case as waiting for disk I/O. It might be
possible to introduce some new flags or functions to allow long
uninterruptible sleeps that do not affect the load, but this has not
been necessary so far because knowledge of this quirk of the load
heuristic is necessary for every great kernel hacker. ;-)
Regards,
Clemens
> > > Uninterruptible sleeps count as I/O load.
> >
> > Is there any practical reason behind this or was it just an
> igenious
> > invention to annoy those smug userspace developers?
>
> Historically, uninterruptible sleeps were the best way to
> detect I/O load. Furthermore, a process that is doing I/O is
> very likely to continue running soon, while other sleeps are
> more likely to indicate that the process is waiting for some
> event to wake it up to begin doing something, so this better
> predicts CPU load. Finally, a busy device is likely to
> prevent other programs from running well, so it makes sense
> to count this against the load.
>
> msleep() is commonly used to handle device communication
> delays, which is essentially the same case as waiting for
> disk I/O. It might be possible to introduce some new flags
> or functions to allow long uninterruptible sleeps that do not
> affect the load, but this has not been necessary so far
> because knowledge of this quirk of the load heuristic is
> necessary for every great kernel hacker. ;-)
So summarizing we could say that semantics for signalling I/O load to
loadavg are historically crippled and msleep() should be avoided if you
don't want to mess up loadavg.
In addition I realize that studying LDD does not make you a great kernel
hacker ;)
Cheers
Dirk