On Sun, Aug 29, 2010 at 08:16:28AM +0200, Michael Blizek wrote: > 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. Doesn't that happen using my process' memory space? I mean, handling the timer doesn't imply that other processes should be run, right? > > > > > 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? Thanks, Michael. I found the problem. If you want to achieve what you just experienced you have to: 1. Set sched_rt_runtime_us to -1 or to the value in sched_rt_period_us 2. VERY important (was my problem, specifically): If you have group scheduling configured, set /cgroup/cpu.rt_runtime_us to -1 (in case you mount the cgroup filesystem on /cgroup Once I set that last value, problem was solved, and I was able to make my processes stuck the others using this: $ time sudo taskset -c 0 chrt -v -f 1 bash -c 'seq 10000000 > /dev/null'& time sudo taskset -c 1 chrt -v -f 1 bash -c 'seq 10000000 > /dev/null' (this was on the machine with two cores) Thanks to everyone, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
