LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
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] " 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
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 \
--subject='Re: [patch] sched: accurate user accounting' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).