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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
