From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: malc <av1474@comtv.ru>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Dmitry Adamushko <dmitry.adamushko@gmail.com>
Subject: Re: [patch] sched: accurate user accounting
Date: Fri, 15 Jun 2007 09:14:25 +0530 [thread overview]
Message-ID: <46720B19.5000006@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706150129430.3526@linmac.oyster.ru>
malc wrote:
> On Thu, 14 Jun 2007, Ingo Molnar wrote:
>
>>
>> * malc <av1474@comtv.ru> wrote:
>>
>>>> the alternating balancing might be due to an uneven number of tasks
>>>> perhaps? If you have 3 tasks on 2 cores then there's no other
>>>> solution to achieve even performance of each task but to rotate them
>>>> amongst the cores.
>>>
>>> One task, one thread. I have also tried to watch fairly demanding
>>> video (Elephants Dream in 1920x1080/MPEG4) with mplayer, and CFS moves
>>> the only task between cores almost every second.
>>
>> hm, mplayer is not running alone when it does video playback: Xorg is
>> also pretty active. Furthermore, the task you are using to monitor
>> mplayer counts too. The Core2Duo has a shared L2 cache between cores, so
>> it is pretty cheap to move tasks between the cores.
>>
>
> Well just to be sure i reran the test with `-vo null' (and fwiw i tried
> few completely different output drivers) the behavior is the same. I'm
> not running Core2Duo but X2, but guess that does not really matter here.
>
> As for the task that monitors, i've written it myself (there are two
> monitoring methods, one(the accurate) does not depend on contets of
> `/proc/stat' at all), so it can be cheaply (for me) changed in any
> way one wants. Sources are available at the same place where screenshot
> was found.
>
>>>> well, precise/finegrained accounting patches have been available for
>>>> years, the thing with CFS is that there we get them 'for free',
>>>> because CFS needs those metrics for its own logic. That's why this
>>>> information is much closer to reality now. But note: right now what
>>>> is affected by the changes in the CFS patches is /proc/PID/stat
>>>> (i.e. the per-task information that 'top' and 'ps' displays, _not_
>>>> /proc/stat) - but more accurate /proc/stat could certainly come
>>>> later on too.
>>>
>>> Aha. I see, it's just that integral load for hog is vastly improved
>>> compared to vanilla 2.6.21 [...]
>>
>> hm, which ones are improved? Could this be due to some other property of
>> CFS? If your app relies on /proc/stat then there's no extra precision in
>> those cpustat values yet.
>
> This is what it looked like before:
> http://www.boblycat.org/~malc/apc/load-x2-hog.png
>
> Now integral load matches the one obtained via the "accurate" method.
> However the report for individual cores are of by around 20% percent.
>
I think I missed some of the context, is the accounting of individual tasks
or cpustat values off by 20%? I'll try and reproduce this problem.
Could you provide more details on the APC tool that you are using -- I
do not understand the orange and yellow lines, do they represent system
and user time?
NOTE: There is some inconsistency in the values reported by /usr/bin/time
(getrusage) and values reported in /proc or through delay accounting.
> Though i'm not quite sure what you mean by "which ones are improved".
>
>> i've Cc:-ed Balbir Singh and Dmitry Adamushko who are the main authors
>> of the current precise accounting code in CFS. Maybe i missed some
>> detail :-)
>
> Oh, the famous "With enough eyeballs, all bugs are shallow." in action.
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
next prev parent reply other threads:[~2007-06-15 3:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-25 1:59 [PATCH] [RFC] sched: accurate user accounting Con Kolivas
2007-03-25 2:14 ` Con Kolivas
2007-03-25 7:51 ` [patch] " Ingo Molnar
2007-03-25 8:39 ` Con Kolivas
2007-03-25 9:04 ` Ingo Molnar
2007-03-25 11:34 ` malc
2007-03-25 11:46 ` Con Kolivas
2007-03-25 12:02 ` Con Kolivas
2007-03-25 12:32 ` Gene Heskett
2007-03-25 12:41 ` Con Kolivas
2007-03-25 13:33 ` Gene Heskett
2007-03-25 13:05 ` malc
2007-03-25 13:06 ` malc
2007-03-25 14:15 ` Con Kolivas
2007-03-25 14:57 ` malc
2007-03-25 15:08 ` Con Kolivas
2007-03-25 15:19 ` malc
2007-03-25 15:28 ` Con Kolivas
2007-03-25 17:14 ` malc
2007-03-25 23:01 ` Con Kolivas
2007-03-25 23:57 ` Con Kolivas
2007-03-26 10:49 ` malc
2007-03-28 11:37 ` Ingo Molnar
2007-06-14 17:56 ` Vassili Karpov
2007-06-14 20:42 ` Ingo Molnar
2007-06-14 20:56 ` malc
2007-06-14 21:18 ` Ingo Molnar
2007-06-14 21:37 ` malc
2007-06-15 3:44 ` Balbir Singh [this message]
2007-06-15 6:07 ` malc
2007-06-16 13:21 ` Balbir Singh
2007-06-16 14:07 ` malc
2007-06-16 18:40 ` Ingo Molnar
2007-06-16 20:31 ` malc
-- strict thread matches above, loose matches on Subject: below --
2007-03-26 5:11 Al Boldi
2007-03-26 5:27 ` Mike Galbraith
2007-03-26 8:45 ` Con Kolivas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46720B19.5000006@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=av1474@comtv.ru \
--cc=dmitry.adamushko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.