Richard Cooper wrote:
What kernel series are you using?
Linux version 2.4.26
Did you compile it yourself?
Possibly, I've compiled kernels before, but I think this one did
everything I needed out of the box, so I didn't have to recompile it.
What is HZ set at?
Aparently 100. I wasn't aware you could change it. I wanted to once
since Linux's multitasking is so sludgy sometimes, but I couldn't
figure out how to do it.
(Turns out the slugyness is because it'll give processes more than one
timeslice in a row, it'll give them like 20 before switching tasks, so
you're only switching tasks 5 times a second. Maybe I should just run
everything under SCHED_RR...)
If it's a 2.6 kernel, did you try enabling preemption?
I'm afraid to try 2.6. I've heard nothing good about it. (in fact,
this is the first time I've seen 2.6 mentioned without being in
relation to something not working because of it)
I know there were teething problems. I suspect a lot of it was due to
widespread use of certain assumptions about kernel behaviour. When the
behaviour changed, it broke libraries and applications. But, it's been
almost 2 years now, and it's not like they're going to be returning to
the 2.4 way of doing things. 2.6 also introduces a lot of improvements
in the way the kernel works.
It's not a problem with kernel threads blocking the scheduling, the
kernel is just sitting idle when I run my test program. As best I can
tell, the kernel simply doesn't want to schedule things outside of it's
10ms time slices. So when I try to sleep for any amount of time, the
wakeup time is always set for the beginning of one of those 10ms
slices. (which is the documented behavior, I'm just surprised to see
that "realtime scheduling" doesn't fix it) It's not that the kernel is
incapable of splitting slices between processes, it does it all the
time. It just won't schedule anything that way.
Realtime scheduling doesn't change the fact that the clock only ticks HZ
times a second. If you've got a 100 Hz tick rate, you'll only do
scheduling on 10 ms intervals. It will split slices between processes,
but (if I recall correctly) only when the kernel is interrupted, and the
scheduler finds that a higher-priority process is ready to run, or
currently running process yields the process (waiting for I/O, or
explicitly yielding). You certainly can't rely on this, and the kernel
has no universally-available way of telling how far into a tick it is.
I don't want to require that people modify their kernel just to run
Softer. The way it is now, you download it, and it just works. (Or it
tells you your in framebuffer mode.) I download Linux programs now and
then, and 75% of the time they don't work. I don't want Softer to be
like that.
The reason it works so well now is because it doesn't depend on
anything. You don't need libraries, you don't even have to compile it,
the binary will work just fine. If people have to modify their kernel,
then it's working becomes dependant on wether or not the kernel
modifications are sucessful. I can make sure that Softer will work,
but I can't do anything to make sure that kernel modifications will work.
Well, the 2.6 kernel has been the mainline kernel since December 2003. I
don't know of any major distros that doesn't distribute a 2.6 kernel,
and most no longer ship 2.4. In addition, several distros, notably
Redhat, shipped 2.4 kernels with the tick rate set at 1000 Hz rather
than 100 in later versions. Unfortunately, Hz (with almost all kernels)
has to be set at kernel compile time (although there is a lot of work
being done trying to set the PIT tick rate dynamically).
I understand why you'd want something that runs with stock kernels.
However, I would suspect that most people are running with kernels using
1000 Hz. Why not embrace that fact, rather than beating your head
against the 100 Hz tick rate?
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
