[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Ingo Molnar <mingo@xxxxxxx> writes:
> thanks for the testing. The important result is that nice--20
> performance is roughly the same as SCHED_ISO. This somewhat
> reduces the urgency of the introduction of SCHED_ISO.
I can see why you feel that way, but don't share your conclusion.
First, only SCHED_FIFO worked reliably in my tests. In Con's tests
even that did not work. My system is probably better tuned for low
latency than his. Until we can determine why there were so many
xruns, it is premature to declare victory for either scheduler.
Preferably, we should compare them on a well-tuned low-latency
system running your Realtime Preemption kernel.
Second, the nice(-20) scheduler provides no clear way to support
multiple realtime priorities. This is necessary for some audio
applications, but not jack_test3.2.
Third, your prototype denies SCHED_FIFO to privileged threads. This
is a serious problem, even for testing (though perhaps easy to fix).
Most important, let's not forget that this long discussion started
because ordinary users need access to realtime scheduling. Con's
scheduler provides a solution for that problem. Your prototype does
Chris Wright and Arjan van de Ven have outlined a proposal to address
the privilege issue using rlimits. This is still the only workable
alternative to the realtime LSM on the table. If the decision were up
to me, I would choose the simplicity and better security of the LSM.
But their approach is adequate, if implemented in a timely fashion. I
would like to see some progress on this in addition to the scheduler
work. People still need SCHED_FIFO for some applications.
Right now, SCHED_ISO still looks better than nice(-20) for audio. It
works without special permissions. The throttling threshold is
adjustable with appropriate privileges. It has the potential to
support multiple priorities.
Being less entangled with SCHED_NORMAL makes me worry less about
someone coming along later and messing it up while working on some
unrelated problem. Right now for example, mounting an encrypted
filesystem starts a `loop0' kernel thread at nice -20.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/