Messages in this thread | | | Subject | Re: [ck] 2.6.16-ck9 | From | Juho Saarikko <> | Date | 02 May 2006 23:57:41 +0300 |
| |
On Tue, 2006-05-02 at 16:38, Con Kolivas wrote: > These are patches designed to improve system responsiveness and interactivity. > It is configurable to any workload but the default ck patch is aimed at the > desktop and cks is available with more emphasis on serverspace. > > THESE INCLUDE THE PATCHES FROM 2.6.16.12 SO START WITH 2.6.16 AS YOUR BASE > > Apply to 2.6.16 > http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.16/2.6.16-ck9/patch-2.6.16-ck9.bz2 > > or server version > http://www.kernel.org/pub/linux/kernel/people/ck/patches/cks/patch-2.6.16-cks9.bz2 > > web: > http://kernel.kolivas.org > > all patches: > http://www.kernel.org/pub/linux/kernel/people/ck/patches/ > > Split patches available. > > > Changes since 2.6.16-ck8: > > Added: > +sched-fix_idleprio.patch > A small bug crept in that prevented SCHED_IDLEPRIO tasks from being scheduled > normally when they held a semaphore making it possible to livelock. This > fixes it.
Hmm...
I tried to run SetiAtHome at IDLEPRIO, but it competes equally with a while(1); loop run at nice 19. I'm starting to wonder if there isn't some kind of bug in the kernel which results in a program returning from a system call with an in-kernel semaphore held. After all, according to top, SetiAtHome consumes over 90% CPU, and the system consumes only about 1%, so it can't be making system calls all the time either. Or maybe there's some case where the calculations can become confused and think that a semaphore is still being held when it's not.
Is there any way to test this ?
Anyway, I ran strace on FahCore (a program, launched by SetiAtHome main program, that actually consumes the CPU), and got this:
rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 nanosleep({5, 0}, {5, 0}) = 0 nanosleep({0, 0}, NULL) = 0
This pattern just keeps on repeating, endlessly. Occasionally it also has
kill(5432, SIG_0) = 0
attached to it. 5432 is the parent process, the FAH502-Linux.exe.
There is something very strange going on here...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |