On Sat, 22 Dec 2007 04:52:50 -0500 Jon Masters <[EMAIL PROTECTED]> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
