On Wed, 2006-05-03 at 01:01, Con Kolivas wrote:
> On Wednesday 03 May 2006 06:57, Juho Saarikko wrote:
> > 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...
>
> Find all the threads running with this command:
> ps -wweALo spid,user,priority,ni,pcpu,vsize,time,args
My version of ps doesn't seem to support spid, but by dropping it I got
the thread pids anyway.
> The spid will show you any threads with different pids to the main task. Then
> check the actual scheduling policy they run at. Perhaps FahCore actually
> manually sets them to SCHED_NORMAL.
And so it does. Annoying. Time to hack kernel to add a new scheduling
policy, SCHED_STAYIDLE, which is like SCHED_IDLE but cannot be unset
except by root.
Can't make it the default, since a program running at SCHED_IDLE in a
machine with 100% CPU usage by some other program will never process
SIGKILL, and thus can only be killed by setting its scheduling policy to
normal...
Darn obnoxious program, SetiAtHome...
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
