Hi!
On 17:56 Sat 28 Aug , Pablo Antonio wrote:
> On Sat, Aug 28, 2010 at 06:35:03PM +0200, Michael Blizek wrote:
> > Hi!
> >
> > On 02:01 Sat 28 Aug , Pablo Antonio wrote:
> > ...
> > > I want to know if it's possible to create a real-time process with
> > > SCHED_FIFO policy that starts running and never lets any other process
> > > run again.
> >
> > Yes, it should be. However hardware interrupts will still arrive.
>
> I don't care about that. All I want is *no other processes* to run ever
> again, but kernel code in my process' context is alright.
This does not only mean "kernel code in my process' context". It also means
timer interrupt, receiving network packets and so.
> > > I had read that processes in SCHED_FIFO usually run until a) they block
> > > themselves by calling some syscall (for example, an I/O request), b)
> > > they are preempted by some higher priority process or c) they decide to
> > > yield the processor. So I thought that technically it would be possible
> > > to create a process that "takes over" the processor from all the other
> > > processes: Just create a SCHED_FIFO process that loops infinitely.
> > >
> > > However, when I tried this it didn't work. Someone told me about
> > > sched_rt_runtime_us and sched_rt_period_us, which acted like a
> > > protection for this cases. So I tried both setting sched_rt_runtime_us
> > > to -1 and setting both values to the same number, but it didn't work
> > > either: I can switch to another terminal, execute top and see the
> > > process running.
> >
> > This is weird. Are you sure that you have put the process in the SCHED_FIFO
> > queue and assigned a static priority > 0 via sched_setscheduler? If you start
> > top and look in the PR column you should see "RT".
>
> Here's something I've been using. The first command sets the runtime value
> to the period value, so real-time process don't leave space for other
> processes to run. The others create process with SCHED_FIFO policy.
>
> $ cat /proc/sys/kernel/sched_rt_period_us | sudo tee /proc/sys/kernel/sched_rt_runtime_us
> $ time sudo chrt -f 99 bash -c 'seq 10000000 > /dev/null'
>
> In a two-core CPU I used:
> $ time sudo chrt -f 99 bash -c 'seq 10000000 > /dev/null' & time sudo chrt -f 99 bash -c 'seq 10000000 > /dev/null'
>
> For some reason, for priority numbers under 99 the PR column doesn't say RT.
> For example, for priority 98 it says -99. Those commands sometimes kind of
> hang the other processes but sometimes they don't.
This is interesing. On my machine (2.6.31.6) the PR column does say RT. If I
start both processes (dual core machine) with sched_rt_runtime_us set, the
machine is stuck to the point where not even the mouse is moving. Maybe there
is an option. Priority -99 look suspicious...
BTW: How many CPUs in /proc/cpuinfo and which version of top do you have?
$ top --version
top: procps version 3.2.8
usage: top -hv | -bcisSH -d delay -n iterations [-u user | -U user] -p pid [,pid ...]
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
