On Sat, 16 Jun 2007, Ingo Molnar wrote:
* malc <[EMAIL PROTECTED]> wrote:
Interesting, the idle time accounting (done from
account_system_time()) has not changed. Has your .config changed?
Could you please send it across. I've downloaded apc and I am trying
to reproduce your problem.
* malc <[EMAIL PROTECTED]> wrote:
> > Interesting, the idle time accounting (done from
> > account_system_time()) has not changed. Has your .config changed?
> > Could you please send it across. I've downloaded apc and I am trying
> > to reproduce your problem.
>
>
On Sat, 16 Jun 2007, Balbir Singh wrote:
malc wrote:
On Fri, 15 Jun 2007, Balbir Singh wrote:
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
[..snip..]
Now integral load matches the one obtained via the "accurate" method.
However the report for individual cores are of by around
malc wrote:
> On Fri, 15 Jun 2007, Balbir Singh wrote:
>
>> malc wrote:
>>> On Thu, 14 Jun 2007, Ingo Molnar wrote:
>>>
>
> [..snip..]
>
>>>
>>> Now integral load matches the one obtained via the "accurate" method.
>>> However the report for individual cores are of by around 20% percent.
>>>
>>
malc wrote:
On Fri, 15 Jun 2007, Balbir Singh wrote:
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
[..snip..]
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
On Sat, 16 Jun 2007, Balbir Singh wrote:
malc wrote:
On Fri, 15 Jun 2007, Balbir Singh wrote:
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
[..snip..]
Now integral load matches the one obtained via the accurate method.
However the report for individual cores are of by around 20%
* malc [EMAIL PROTECTED] wrote:
Interesting, the idle time accounting (done from
account_system_time()) has not changed. Has your .config changed?
Could you please send it across. I've downloaded apc and I am trying
to reproduce your problem.
http://www.boblycat.org/~malc/apc/cfs/
On Sat, 16 Jun 2007, Ingo Molnar wrote:
* malc [EMAIL PROTECTED] wrote:
Interesting, the idle time accounting (done from
account_system_time()) has not changed. Has your .config changed?
Could you please send it across. I've downloaded apc and I am trying
to reproduce your problem.
On Fri, 15 Jun 2007, Balbir Singh wrote:
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
[..snip..]
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
On Fri, 15 Jun 2007, Balbir Singh wrote:
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
[..snip..]
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
malc wrote:
> On Thu, 14 Jun 2007, Ingo Molnar wrote:
>
>>
>> * malc <[EMAIL PROTECTED]> 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
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* malc <[EMAIL PROTECTED]> 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.
* malc <[EMAIL PROTECTED]> 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
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* Vassili Karpov <[EMAIL PROTECTED]> wrote:
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few
refernces to accounting i decided to give CFS a try. With
sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems
* Vassili Karpov <[EMAIL PROTECTED]> wrote:
> Hello Ingo and others,
>
> After reading http://lwn.net/Articles/236485/ and noticing few
> refernces to accounting i decided to give CFS a try. With
> sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems like
> scheduler is dead set on
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few refernces
to accounting i decided to give CFS a try. With sched-cfs-v2.6.21.4-16
i get pretty weird results, it seems like scheduler is dead set on trying
to move the processes to different CPUs/cores all the
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few refernces
to accounting i decided to give CFS a try. With sched-cfs-v2.6.21.4-16
i get pretty weird results, it seems like scheduler is dead set on trying
to move the processes to different CPUs/cores all the
* Vassili Karpov [EMAIL PROTECTED] wrote:
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few
refernces to accounting i decided to give CFS a try. With
sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems like
scheduler is dead set on trying to
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* Vassili Karpov [EMAIL PROTECTED] wrote:
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few
refernces to accounting i decided to give CFS a try. With
sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems like
* malc [EMAIL PROTECTED] 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
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* malc [EMAIL PROTECTED] 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.
malc wrote:
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* malc [EMAIL PROTECTED] 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
* malc <[EMAIL PROTECTED]> wrote:
> This situation is harder to write a hog-like testcase for. Anyhow it
> seems the difference in percentage stems from the `intr' field of
> `/proc/stat', which fits. And following patch (which should be applied
> on top of yours) seems to help. I wouldn't
* malc [EMAIL PROTECTED] wrote:
This situation is harder to write a hog-like testcase for. Anyhow it
seems the difference in percentage stems from the `intr' field of
`/proc/stat', which fits. And following patch (which should be applied
on top of yours) seems to help. I wouldn't really
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 09:01, Con Kolivas wrote:
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
Erm... i just looked at the code and suddenly it stopped making any sense
On Monday 26 March 2007 15:11, Al Boldi wrote:
> Con Kolivas wrote:
> > Ok this one is heavily tested. Please try it when you find the time.
>
> It's better, but still skewed. Try two chew.c's; they account 80% each.
>
> > ---
> > Currently we only do cpu accounting to userspace based on what is
On Monday 26 March 2007 15:11, Al Boldi wrote:
Con Kolivas wrote:
Ok this one is heavily tested. Please try it when you find the time.
It's better, but still skewed. Try two chew.c's; they account 80% each.
---
Currently we only do cpu accounting to userspace based on what is
actually
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 09:01, Con Kolivas wrote:
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
Erm... i just looked at the code and suddenly it stopped making any sense
On Mon, 2007-03-26 at 08:11 +0300, Al Boldi wrote:
> > + /* Sanity check. It should never go backwards or ruin accounting
> > */ + if (unlikely(now < p->last_ran))
> > + goto out_set;
>
> If sched_clock() goes backwards, why not fix it, instead of hacking around
> it?
Con Kolivas wrote:
>
> Ok this one is heavily tested. Please try it when you find the time.
It's better, but still skewed. Try two chew.c's; they account 80% each.
> ---
> Currently we only do cpu accounting to userspace based on what is
> actually happening precisely on each tick. The accuracy
On Monday 26 March 2007 09:01, Con Kolivas wrote:
> On Monday 26 March 2007 03:14, malc wrote:
> > On Mon, 26 Mar 2007, Con Kolivas wrote:
> > > On Monday 26 March 2007 01:19, malc wrote:
> > Erm... i just looked at the code and suddenly it stopped making any sense
> > at all:
> >
> >
On Monday 26 March 2007 03:14, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > On Monday 26 March 2007 01:19, malc wrote:
> >> On Mon, 26 Mar 2007, Con Kolivas wrote:
> >>> So before we go any further with this patch, can you try the following
> >>> one and see if this simple sanity
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough?
Sure (compiling the kernel now), too bad old
On Monday 26 March 2007 01:19, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > So before we go any further with this patch, can you try the following
> > one and see if this simple sanity check is enough?
>
> Sure (compiling the kernel now), too bad old axiom that testing can not
>
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 00:57, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34,
On Monday 26 March 2007 00:57, malc wrote:
> On Mon, 26 Mar 2007, Con Kolivas wrote:
> > On Sunday 25 March 2007 23:06, malc wrote:
> >> On Sun, 25 Mar 2007, Con Kolivas wrote:
> >>> On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> On Sunday 25 March 2007 21:34, malc wrote:
> > On Sun,
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]>
On Sunday 25 March 2007 23:06, malc wrote:
> On Sun, 25 Mar 2007, Con Kolivas wrote:
> > On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> >> On Sunday 25 March 2007 21:34, malc wrote:
> >>> On Sun, 25 Mar 2007, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > For an
On Sunday 25 March 2007, Con Kolivas wrote:
>On Sunday 25 March 2007 22:32, Gene Heskett wrote:
>> On Sunday 25 March 2007, Con Kolivas wrote:
>> >On Sunday 25 March 2007 21:46, Con Kolivas wrote:
>> >> On Sunday 25 March 2007 21:34, malc wrote:
>> >> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
>>
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
[..snip..]
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do
On Sunday 25 March 2007 22:32, Gene Heskett wrote:
> On Sunday 25 March 2007, Con Kolivas wrote:
> >On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> >> On Sunday 25 March 2007 21:34, malc wrote:
> >> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
> >> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
>
On Sunday 25 March 2007, Con Kolivas wrote:
>On Sunday 25 March 2007 21:46, Con Kolivas wrote:
>> On Sunday 25 March 2007 21:34, malc wrote:
>> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
>> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
>> > >> For an rsdl 0.33 patched kernel. Comments? Overhead
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
> On Sunday 25 March 2007 21:34, malc wrote:
> > On Sun, 25 Mar 2007, Ingo Molnar wrote:
> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > >> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
> > >
> > > we want to do this - and we
On Sunday 25 March 2007 21:34, malc wrote:
> On Sun, 25 Mar 2007, Ingo Molnar wrote:
> > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> >> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
> >
> > we want to do this - and we should do this to the vanilla scheduler
> > first and check the
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've back-merged the patch to before RSDL
and have
HZ))
> > +
>
> This hunk is already in mainline so it will be double defined now.
yeah. Updated patch below.
Ingo
-->
Subject: [patch] sched: accurate user accounting
From: Con Kolivas <[EMAIL PROTECTED]>
Currently we only do cpu accounting to userspa
On Sunday 25 March 2007 17:51, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
>
> we want to do this - and we should do this to the vanilla scheduler
> first and check the results. I've back-merged the patch to before
low. Vale, could you try this
patch against a 2.6.21-rc4-ish kernel and re-test your testcase?
Ingo
->
Subject: [patch] sched: accurate user accounting
From: Con Kolivas <[EMAIL PROTECTED]>
Currently we only do cpu accounting to userspace based on what is
, could you try this
patch against a 2.6.21-rc4-ish kernel and re-test your testcase?
Ingo
-
Subject: [patch] sched: accurate user accounting
From: Con Kolivas [EMAIL PROTECTED]
Currently we only do cpu accounting to userspace based on what is
actually happening precisely
On Sunday 25 March 2007 17:51, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've back-merged the patch to before RSDL
it will be double defined now.
yeah. Updated patch below.
Ingo
--
Subject: [patch] sched: accurate user accounting
From: Con Kolivas [EMAIL PROTECTED]
Currently we only do cpu accounting to userspace based on what is
actually happening precisely on each tick. The accuracy
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've back-merged the patch to before RSDL
and have
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the vanilla scheduler
first and check the results. I've
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do this - and we should do this to the
On Sunday 25 March 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we
On Sunday 25 March 2007 22:32, Gene Heskett wrote:
On Sunday 25 March 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
we want to do
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
[..snip..]
On Sunday 25 March 2007, Con Kolivas wrote:
On Sunday 25 March 2007 22:32, Gene Heskett wrote:
On Sunday 25 March 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
For an rsdl 0.33 patched kernel.
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED]
On Monday 26 March 2007 00:57, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34, malc wrote:
On Sun, 25 Mar 2007, Ingo
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 00:57, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 23:06, malc wrote:
On Sun, 25 Mar 2007, Con Kolivas wrote:
On Sunday 25 March 2007 21:46, Con Kolivas wrote:
On Sunday 25 March 2007 21:34,
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough?
Sure (compiling the kernel now), too bad old axiom that testing can not
confirm
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough?
Sure (compiling the kernel now), too bad old
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
So before we go any further with this patch, can you try the following
one and see if this simple sanity check is enough?
On Monday 26 March 2007 09:01, Con Kolivas wrote:
On Monday 26 March 2007 03:14, malc wrote:
On Mon, 26 Mar 2007, Con Kolivas wrote:
On Monday 26 March 2007 01:19, malc wrote:
Erm... i just looked at the code and suddenly it stopped making any sense
at all:
p-last_ran =
Con Kolivas wrote:
Ok this one is heavily tested. Please try it when you find the time.
It's better, but still skewed. Try two chew.c's; they account 80% each.
---
Currently we only do cpu accounting to userspace based on what is
actually happening precisely on each tick. The accuracy of
On Mon, 2007-03-26 at 08:11 +0300, Al Boldi wrote:
+ /* Sanity check. It should never go backwards or ruin accounting
*/ + if (unlikely(now p-last_ran))
+ goto out_set;
If sched_clock() goes backwards, why not fix it, instead of hacking around
it?
When tasks
70 matches
Mail list logo
