Hello,
I have BOINC running in the background with niceness 19.
With a 2.6.22 kernel, only idle cpu cycles get assigned to this process, as
expected.
But with the 2.6.24 kernel, the BOINC process gets at least about half of
all CPU cycles, even if there's another process (owned by another user)
requesting CPU cycles (e.g. "cat /dev/urandom > /dev/null")
This happens with the Ubuntu kernel (from Hardy) and the daily builds from
http://kernel-archive.buildserver.net/debian-kernel/ (where I've just tested
rc8 now).
It appears that every user (here "boinc" and my user) get the same portion
of the overall CPU cycles, regardless of the process niceness.
Is this expected behaviour?
I'm using an AMD64 3000+ processor. Please ask for additional information, if
you need it (e.g. kernel config).
TESTCASE:
$ cat /dev/urandom > /dev/null &
$ sudo -u another_user nice -n 19 python -c 'i = 0;
while 1:
i += i
'
EXPECTED RESULT:
The niced process should get nearly no CPU cycles.
ACTUAL RESULT:
The niced process gets about half of the CPU cycles (according to "top").
The bug has been reported for Ubuntu on https://launchpad.net/bugs/177713
--
http://daniel.hahler.de/
Hello,
I've now found the reason and a workaround for this. Apparently, it's
related to CONFIG_FAIR_USER_SCHED and can be worked around by
assigning a really small value to the boinc users cpu_share (125 is
the uid of "boinc"):
$ echo 2 | sudo tee /sys/kernel/uids/125/cpu_share
While looking around, I've found the following patch, which seems to
address this:
http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/3849.html
It has been posted here, but without any response.
btw: writing 1 into "cpu_share" totally locks up the computer!
Cheers.
On Jan 19, 2008 3:05 PM, I wrote:
> Hello,
>
> I have BOINC running in the background with niceness 19.
> With a 2.6.22 kernel, only idle cpu cycles get assigned to this process, as
> expected.
>
> But with the 2.6.24 kernel, the BOINC process gets at least about half of
> all CPU cycles, even if there's another process (owned by another user)
> requesting CPU cycles (e.g. "cat /dev/urandom > /dev/null")
>
> This happens with the Ubuntu kernel (from Hardy) and the daily builds from
> http://kernel-archive.buildserver.net/debian-kernel/ (where I've just tested
> rc8 now).
>
> It appears that every user (here "boinc" and my user) get the same portion
> of the overall CPU cycles, regardless of the process niceness.
>
> Is this expected behaviour?
>
> I'm using an AMD64 3000+ processor. Please ask for additional information, if
> you need it (e.g. kernel config).
>
>
> TESTCASE:
> $ cat /dev/urandom > /dev/null &
> $ sudo -u another_user nice -n 19 python -c 'i = 0;
> while 1:
> i += i
> '
>
> EXPECTED RESULT:
> The niced process should get nearly no CPU cycles.
>
> ACTUAL RESULT:
> The niced process gets about half of the CPU cycles (according to "top").
>
>
> The bug has been reported for Ubuntu on https://launchpad.net/bugs/177713
>
>
> --
> http://daniel.hahler.de/
>
--
http://daniel.hahler.de/
On Sat, Jan 19, 2008 at 03:52:44PM +0100, dAniel hAhler wrote:
> Hello,
>
> I've now found the reason and a workaround for this. Apparently, it's
> related to CONFIG_FAIR_USER_SCHED and can be worked around by
> assigning a really small value to the boinc users cpu_share (125 is
> the uid of "boinc"):
> $ echo 2 | sudo tee /sys/kernel/uids/125/cpu_share
>
Correct, that is the way to go about it.
> While looking around, I've found the following patch, which seems to
> address this:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/3849.html
>
> It has been posted here, but without any response.
>
> btw: writing 1 into "cpu_share" totally locks up the computer!
>
Can you please provide some more details. Can you go into another
console (try ctrl-alt-f1) and try to reproduce the issue there. Could
you take a photo of the oops/panic and upload it somewhere so that we
can see it?
Thanks
--
regards,
Dhaval
On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote:
> On Sat, Jan 19, 2008 at 03:52:44PM +0100, dAniel hAhler wrote:
> > Hello,
> >
> > I've now found the reason and a workaround for this. Apparently, it's
> > related to CONFIG_FAIR_USER_SCHED and can be worked around by
> > assigning a really small value to the boinc users cpu_share (125 is
> > the uid of "boinc"):
> > $ echo 2 | sudo tee /sys/kernel/uids/125/cpu_share
> >
>
> Correct, that is the way to go about it.
>
> > While looking around, I've found the following patch, which seems to
> > address this:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/3849.html
> >
> > It has been posted here, but without any response.
> >
> > btw: writing 1 into "cpu_share" totally locks up the computer!
> >
>
> Can you please provide some more details. Can you go into another
> console (try ctrl-alt-f1) and try to reproduce the issue there. Could
> you take a photo of the oops/panic and upload it somewhere so that we
> can see it?
>
I've not been able to reproduce this problem on my system here. Do you
try to change the cpu_share of the current user?
--
regards,
Dhaval
On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote:
> > btw: writing 1 into "cpu_share" totally locks up the computer!
> >
>
> Can you please provide some more details. Can you go into another
> console (try ctrl-alt-f1) and try to reproduce the issue there. Could
> you take a photo of the oops/panic and upload it somewhere so that we
> can see it?
I couldn't recreate this problem either on 2.6.24-rc8.
Daniel,
Could you pass the config file you used pls?
--
Regards,
vatsa
On Jan 21, 2008 6:18 PM, Srivatsa Vaddagiri wrote:
> On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote:
> > > btw: writing 1 into "cpu_share" totally locks up the computer!
> > >
> >
> > Can you please provide some more details. Can you go into another
> > console (try ctrl-alt-f1) and try to reproduce the issue there. Could
> > you take a photo of the oops/panic and upload it somewhere so that we
> > can see it?
>
> I couldn't recreate this problem either on 2.6.24-rc8.
>
> Daniel,
> Could you pass the config file you used pls?
Sure, I've uploaded the config to
http://codeprobe.de/tmp/config-2.6.24-4-generic
It only happens when changing the cpu_share for another user and this
user needs to have a cpu hogging process running (like boinc, a
while-1 loop or similar).
It does not dump anything to the console, but the VirtualBox process
on the host takes all CPU - there seems to be no crash, but an endless
loop only.
I have reported it at http://bugzilla.kernel.org/show_bug.cgi?id=9779
already, with a testcase (outlined above).
Thank you for your help.
--
http://daniel.hahler.de/