Messages in this thread | | | Date | Sat, 22 Dec 2007 02:11:35 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] kthread: run kthreadd with max priority SCHED_FIFO |
| |
On Sat, 22 Dec 2007 04:52:50 -0500 Jon Masters <jcm@redhat.com> wrote:
> > The general approach we've taken to this is "don't do that". Yes, we could > > boost lots of kernel threads in the way which this patch does but this > > actually takes control *away* from userspace. Userspace no longer has the > > ability to guarantee itself minimum possible latency without getting > > preempted by kernel threads. > > > > And yes, giving userspace this minimum-latency capability does imply that > > userspace has a responsibility to not 100% starve kernel threads. It's a > > reasonable compromise, I think? > > So, user tasks running with SCHED_FIFO should be able to lock a system?
yup. root can damage the system in all sorts of ways.
> I guess I see both sides of this argument - yes, it's userspace at > fault, but in other cases when userspace is at fault, we take action > (OOM, segfault, others). Isn't this situation just another case where > the kernel needs to avoid the evils of userland going awry?
Well... the problem is that if we add a safety net to catch run-away SCHED_FIFO processes, we've permanently degraded the service which we provide to well-behaved programs.
Should there be a watchdog which checks for a process which has run realtime for a certain period and which then takes some action? Such as descheduling it for a while, generating warnings, demoting its policy, killing it etc?
| |