How is run queue length computed in linux proc filesystem

How is run queue length computed in linux proc filesystem

[emani murali]

Hi,

I'm trying to obtain number of runnable processes from linux kernel. sar -q
gives this information readily. However I'm trying to get this value from
/proc filesystem. There is no file in /proc that gives this value directly,
then how is runq-sz computed.

The wiki page http://en.wikipedia.org/wiki/Load_(computing) provides some
insight into how run queue length is computed based on ldavg values but it
is unclear. Can someone provide more pointers on this. Cheers

Thanks,
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130816/9f018c50/attachment.html 

How is run queue length computed in linux proc filesystem

[Valdis.Kletnieks at vt.edu]

On Fri, 16 Aug 2013 14:20:29 +0100, emani murali said:

> I'm trying to obtain number of runnable processes from linux kernel.

Why are you trying to get that number, and how important is accuracy?
(Remember that the value of that number can change literally several
tens of thousands of times per second).

> The wiki page http://en.wikipedia.org/wiki/Load_(computing) provides some
> insight into how run queue length is computed based on ldavg values but it
> is unclear. Can someone provide more pointers on this. Cheers

Actually, you have that backwards.  Load average is computed based on run queue
length.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130816/b04a1c69/attachment-0001.bin 

How is run queue length computed in linux proc filesystem

[emani murali]

Exactly, I would like to know how is runq computed from load average. Are
there any system calls to get this value.

Cheers,
Kris

On 16 August 2013 14:46, <Valdis.Kletnieks@vt.edu> wrote:

> On Fri, 16 Aug 2013 14:20:29 +0100, emani murali said:
>
> > I'm trying to obtain number of runnable processes from linux kernel.
>
> Why are you trying to get that number, and how important is accuracy?
> (Remember that the value of that number can change literally several
> tens of thousands of times per second).
>
> > The wiki page http://en.wikipedia.org/wiki/Load_(computing) provides
> some
> > insight into how run queue length is computed based on ldavg values but
> it
> > is unclear. Can someone provide more pointers on this. Cheers
>
> Actually, you have that backwards.  Load average is computed based on run
> queue
> length.
>



-- 
Thanks,
Murali Krishna Emani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130816/58d38256/attachment.html 

How is run queue length computed in linux proc filesystem

[Valdis.Kletnieks at vt.edu]

On Fri, 16 Aug 2013 14:51:59 +0100, emani murali said:

> Exactly, I would like to know how is runq computed from load average. Are
> there any system calls to get this value.

Load average is computed from runq.  Not the other way around. Given runq,
you can comput load average.  Given load average, ti's very difficult to
compute runq.

Omeletts are made from eggs.  Not the other way around.  Given an egg,
you can create an omelette.  Given an omelette, it's very difficult to
make an egg.

The problem is that runq changes many times per second (potentially at
every system call, and it doesn't take much hardware to do a quarter million
system calls per second).  Load average is a smoothed average value, and
as such, loses information.  If I tell you that the average amount of folding
money in my wallet during July was $5.89, you can't figure out how much
was in my wallet at 2PM on July 12, or if there was $8 more in it at 10AM
that morning and I paid for lunch with cash that day.

There's also the minor detail that the *average* inclues 89 cents - but
folding money in the US is always an integer. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130816/827d1fef/attachment.bin 

How is run queue length computed in linux proc filesystem

[Rik van Riel]

On 08/16/2013 09:20 AM, emani murali wrote:
> Hi,
>
> I'm trying to obtain number of runnable processes from linux kernel. sar
> -q gives this information readily. However I'm trying to get this value
> from /proc filesystem. There is no file in /proc that gives this value
> directly, then how is runq-sz computed.

Tools like top, vmstat, and sar, simply look at all the processes
in /proc, and count the number that are in runnable (R) state.

-- 
All rights reversed.

How is run queue length computed in linux proc filesystem

[Valdis.Kletnieks at vt.edu]

On Fri, 16 Aug 2013 12:57:23 -0400, Rik van Riel said:
> On 08/16/2013 09:20 AM, emani murali wrote:
> > Hi,
> >
> > I'm trying to obtain number of runnable processes from linux kernel. sar
> > -q gives this information readily. However I'm trying to get this value
> > from /proc filesystem. There is no file in /proc that gives this value
> > directly, then how is runq-sz computed.
>
> Tools like top, vmstat, and sar, simply look at all the processes
> in /proc, and count the number that are in runnable (R) state.

Which is why I asked what Emani is trying to do - scanning /proc is
inherently racy, and the runq-sz value can change and/or be different than
counting the number of runnable processes.  A slight bit of jitter in the
output of top probably doesn't matter.  Feeding the number back into a
scheduler loop or something like that may matter a lot...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130816/c8ce978b/attachment.bin