Re: [ck] 2.6.16-ck9

[Juho Saarikko <juhos@mbnet.fi>]

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/