> (...) You can only guarantee a response time by mlock(2)ing a
> process in core.
This will not help you out of every problem if it was another task
that caused the kswapd activity. In general, the best way to get best
results is to avoid *any* kind of I/O activity. Well, that is, as much
of it as possible.
BTW, one idea I've been playing with in order to improve this:
We've got these BH handlers to do time-uncritical stuff, ok? If it
really was time-uncritical it shouldn't matter if we didn't execute
them when a RT task is to be run. Some buffers would fill, but as long
as this situation doesn't hold for too long it should work. But then I
see that the scheduler itself calls all BH, probably because only the
BH set tasks to be runnable again after waiting for some I/O.
The problem is that whether a task is RT or not has *no* effect on
how scheduling is done once it got activated, the chain of execution
is always the same, it goes through all the BHs. Under Solaris, e.g.,
RT scheduling works in a different way, because you can see that a RT
task gets scheduled quicker than a !RT task. I guess they just "ommit"
some non-vital "BH", or kernel-threads or however you'd like to call
it. Under Linux there is no such difference, each task takes the same
time for scheduling, RT tasks are *not* "faster at the draw".
Just an idea so far, and still full of open problems...
ciao,
TeSche
-- Torsten Scherer (Schiller, TeSche...), itschere@techfak.uni-bielefeld.de Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...