At Monday 04 February 2008 Pallipadi, Venkatesh wrote :
>
> This looks like is related to the report here
> http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/1260.html
>
> Can you try the workarounds on that thread and see whether the problem goes
> away.
>
Yes, I already answered here :
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Morton
>Sent: Sunday, February 03, 2008 4:33 PM
>To: Toralf Förster
>Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
>Subject: Re: (ondemand) CPU governor regr
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Morton
Sent: Sunday, February 03, 2008 4:33 PM
To: Toralf Förster
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: (ondemand) CPU governor regression between 2.6.23
and 2.6.24
At Monday 04 February 2008 Pallipadi, Venkatesh wrote :
This looks like is related to the report here
http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/1260.html
Can you try the workarounds on that thread and see whether the problem goes
away.
Yes, I already answered here :
On Sun, 3 Feb 2008 16:32:55 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> If nothing happens (often the case), please raise a report at
> bugzilla.kernel.org so we can track the presence of the regression.
argh, please ignore. I got bitten by the
On Sat, 26 Jan 2008 15:06:25 +0100 Toralf Förster <[EMAIL PROTECTED]> wrote:
> I use a 1-liner for a simple performance check : "time factor
> 819734028463158891"
> Here is the result for the new (Gentoo) kernel 2.6.24:
>
> With the ondemand governor of the I get:
>
> [EMAIL PROTECTED] ~/tmp
On Sun, 3 Feb 2008 16:32:55 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
If nothing happens (often the case), please raise a report at
bugzilla.kernel.org so we can track the presence of the regression.
argh, please ignore. I got bitten by the
im-too-lame-to-get-my-References:-header-right
On Sat, 26 Jan 2008 15:06:25 +0100 Toralf Förster [EMAIL PROTECTED] wrote:
I use a 1-liner for a simple performance check : time factor
819734028463158891
Here is the result for the new (Gentoo) kernel 2.6.24:
With the ondemand governor of the I get:
[EMAIL PROTECTED] ~/tmp $ time
Hello,
At Monday 28 January 2008 Ingo Molnar wrote :
>
> it splits the CPU time between Xorg (root UID) and desktop apps. This
> helps particularly well when there's compile jobs going on, etc. - Xorg
good news for all Gentoo users ;)
> So if you have some time to play with this, could you
Toralf, for me the group scheduler offers superior interactivity on my
laptop for a number of reasons. The biggest practical effect is because
it splits the CPU time between Xorg (root UID) and desktop apps. This
helps particularly well when there's compile jobs going on, etc. - Xorg
still
Toralf Förster wrote:
At Sunday 27 January 2008 Srivatsa Vaddagiri wrote :
You can set that to 0 to ask ondemand gov to include nice load into
account while calculating cpu freq changes:
# echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
This should restore the
Hello,
At Monday 28 January 2008 Ingo Molnar wrote :
it splits the CPU time between Xorg (root UID) and desktop apps. This
helps particularly well when there's compile jobs going on, etc. - Xorg
good news for all Gentoo users ;)
So if you have some time to play with this, could you please
Toralf Förster wrote:
At Sunday 27 January 2008 Srivatsa Vaddagiri wrote :
You can set that to 0 to ask ondemand gov to include nice load into
account while calculating cpu freq changes:
# echo 0 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
This should restore the
Toralf, for me the group scheduler offers superior interactivity on my
laptop for a number of reasons. The biggest practical effect is because
it splits the CPU time between Xorg (root UID) and desktop apps. This
helps particularly well when there's compile jobs going on, etc. - Xorg
still
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-01-27 at 17:57 +0100, Toralf Förster wrote:
>
> > It would be nice to run a grid application at lowest priority
> > without impact to power / fan / temperature but OTOH have full
> > performance for desktop applications, isn't it ?
>
On Sun, 2008-01-27 at 17:57 +0100, Toralf Förster wrote:
> It would be nice to run a grid application at lowest priority without impact
> to
> power / fan / temperature but OTOH have full performance for desktop
> applications, isn't it ?
This can be achieved by giving the group/uid the grid
On Sun, 2008-01-27 at 22:14 +0100, Toralf Förster wrote:
> Is it correct that within the scenario described above user "A" never gets
> more
> than 50% of the CPU as soon as user "B" is logged into the system (because of
> the login process itself) ?
No, the login process doesn't normally
At Sunday 27 January 2008 Mike Galbraith wrote :
>
> On Sun, 2008-01-27 at 13:39 +0100, Toralf Förster wrote:
> > Ough, does this mean that for a multi-user scenario of 2 non-root users "A"
> > and
> > "B" each running exactly 1 process with nice level 0 and 19 rerspectively
> > that both share
On Sun, 2008-01-27 at 13:39 +0100, Toralf Förster wrote:
> Am Sonntag, 27. Januar 2008 schrieben Sie:
> >
> > On Sun, 2008-01-27 at 12:00 +0100, Toralf Förster wrote:
> > > BTW the dnetc process runs under the user "dnetc" with nice level -19,
> > > my process runs under my own user id
At Sunday 27 January 2008 Srivatsa Vaddagiri wrote :
> You can set that to 0 to ask ondemand gov to include nice load into
> account while calculating cpu freq changes:
>
> # echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
>
> This should restore the behavior of ondemand
On Sun, Jan 27, 2008 at 04:06:17PM +0100, Toralf Förster wrote:
> > The third line (giving overall cpu usage stats) is what is interesting here.
> > If you have more than one cpu, you can get cpu usage stats for each cpu
> > in top by pressing 1. Can you provide this information with and w/o
> >
Am Sonntag, 27. Januar 2008 schrieb Srivatsa Vaddagiri:
> On Sat, Jan 26, 2008 at 07:46:51PM +0100, Toralf Förster wrote:
> >
> > The problem is the same as described here :
> > http://lkml.org/lkml/2007/10/21/85
> > If I run dnetc even with lowest prority than the CPU stays at 600 MHz
> >
On Sat, Jan 26, 2008 at 07:46:51PM +0100, Toralf Förster wrote:
>
> The problem is the same as described here : http://lkml.org/lkml/2007/10/21/85
> If I run dnetc even with lowest prority than the CPU stays at 600 MHz
> regardless
> of any other load (eg. rsyncing, svn update, compiling, ...)
>
Am Sonntag, 27. Januar 2008 schrieben Sie:
>
> On Sun, 2008-01-27 at 12:00 +0100, Toralf Förster wrote:
> > BTW the dnetc process runs under the user "dnetc" with nice level -19,
> > my process runs under my own user id "tfoerste" therefore I wouldn't expect
> > that both processes got the same
Am Sonntag, 27. Januar 2008 schrieben Sie:
On Sun, 2008-01-27 at 12:00 +0100, Toralf Förster wrote:
BTW the dnetc process runs under the user dnetc with nice level -19,
my process runs under my own user id tfoerste therefore I wouldn't expect
that both processes got the same processor
On Sun, Jan 27, 2008 at 04:06:17PM +0100, Toralf Förster wrote:
The third line (giving overall cpu usage stats) is what is interesting here.
If you have more than one cpu, you can get cpu usage stats for each cpu
in top by pressing 1. Can you provide this information with and w/o
At Sunday 27 January 2008 Srivatsa Vaddagiri wrote :
You can set that to 0 to ask ondemand gov to include nice load into
account while calculating cpu freq changes:
# echo 0 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
This should restore the behavior of ondemand
On Sun, 2008-01-27 at 13:39 +0100, Toralf Förster wrote:
Am Sonntag, 27. Januar 2008 schrieben Sie:
On Sun, 2008-01-27 at 12:00 +0100, Toralf Förster wrote:
BTW the dnetc process runs under the user dnetc with nice level -19,
my process runs under my own user id tfoerste therefore I
At Sunday 27 January 2008 Mike Galbraith wrote :
On Sun, 2008-01-27 at 13:39 +0100, Toralf Förster wrote:
Ough, does this mean that for a multi-user scenario of 2 non-root users A
and
B each running exactly 1 process with nice level 0 and 19 rerspectively
that both share ~50% of the
On Sun, 2008-01-27 at 22:14 +0100, Toralf Förster wrote:
Is it correct that within the scenario described above user A never gets
more
than 50% of the CPU as soon as user B is logged into the system (because of
the login process itself) ?
No, the login process doesn't normally consume any
On Sun, 2008-01-27 at 17:57 +0100, Toralf Förster wrote:
It would be nice to run a grid application at lowest priority without impact
to
power / fan / temperature but OTOH have full performance for desktop
applications, isn't it ?
This can be achieved by giving the group/uid the grid
* Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sun, 2008-01-27 at 17:57 +0100, Toralf Förster wrote:
It would be nice to run a grid application at lowest priority
without impact to power / fan / temperature but OTOH have full
performance for desktop applications, isn't it ?
This can
Added Ingo + Peter.
Sam
On Sat, Jan 26, 2008 at 10:38:15PM +0100, Toralf Förster wrote:
> It seems to be rather a scheduler issue than a governor issue b/c
> the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
>
> If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises
It seems to be rather a scheduler issue than a governor issue b/c
the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises 80%
- which forces the ondemand governor do speed up the CPU frequency:
PID USER PR NI VIRT
The problem is the same as described here : http://lkml.org/lkml/2007/10/21/85
If I run dnetc even with lowest prority than the CPU stays at 600 MHz regardless
of any other load (eg. rsyncing, svn update, compiling, ...)
Stopping the dnetc process immediately speeds up the CPU up to 1.7 GHz.
Toralf Förster wrote:
I use a 1-liner for a simple performance check : "time factor
819734028463158891"
Here is the result for the new (Gentoo) kernel 2.6.24:
With the ondemand governor of the I get:
[EMAIL PROTECTED] ~/tmp $ time factor 819734028463158891
819734028463158891: 3
I use a 1-liner for a simple performance check : "time factor
819734028463158891"
Here is the result for the new (Gentoo) kernel 2.6.24:
With the ondemand governor of the I get:
[EMAIL PROTECTED] ~/tmp $ time factor 819734028463158891
819734028463158891: 3 273244676154386297
real
Toralf Förster wrote:
I use a 1-liner for a simple performance check : time factor
819734028463158891
Here is the result for the new (Gentoo) kernel 2.6.24:
With the ondemand governor of the I get:
[EMAIL PROTECTED] ~/tmp $ time factor 819734028463158891
819734028463158891: 3
The problem is the same as described here : http://lkml.org/lkml/2007/10/21/85
If I run dnetc even with lowest prority than the CPU stays at 600 MHz regardless
of any other load (eg. rsyncing, svn update, compiling, ...)
Stopping the dnetc process immediately speeds up the CPU up to 1.7 GHz.
It seems to be rather a scheduler issue than a governor issue b/c
the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises 80%
- which forces the ondemand governor do speed up the CPU frequency:
PID USER PR NI VIRT
Added Ingo + Peter.
Sam
On Sat, Jan 26, 2008 at 10:38:15PM +0100, Toralf Förster wrote:
It seems to be rather a scheduler issue than a governor issue b/c
the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises 80%
41 matches
Mail list logo
