[lkml]   [2007]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] kthread: run kthreadd with max priority SCHED_FIFO
    On Sat, 22 Dec 2007 04:52:50 -0500 Jon Masters <> 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?

     \ /
      Last update: 2007-12-22 11:15    [W:0.021 / U:4.812 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site