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 :
ht
>-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
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-righ
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
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 ple
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 get
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 behavi
* 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 ap
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 consu
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 "tfoerste"
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 g
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
> > C
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
> > regar
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 pr
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 RE
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.
Am
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 273244676154
21 matches
Mail list logo
