Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rtscheduling

[Jack O'Quin]

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
  not.

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.
-- 
  joq
-
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/