Re: scheduler (sched_4bsd) questions

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/29/04

  • Next message: Daniel Eischen: "Re: sched_userret priority adjustment patch for sched_4bsd" 
    To: freebsd-arch@FreeBSD.org
Date: Wed, 29 Sep 2004 16:52:29 -0400

    On Wednesday 29 September 2004 04:26 pm, Stephan Uphoff wrote:
    > Forgot to attach the patch ...
    >
    > Stephan
    >
    > On Wed, 2004-09-29 at 13:12, Stephan Uphoff wrote:
    > > On Wed, 2004-09-29 at 10:24, Stephan Uphoff wrote:
    > > > On Wed, 2004-09-29 at 04:57, Peter Holm wrote:
    > > > > It's hard for me to tell if your patch has made any difference.
    > > > > The freeze is still there. I'll try to make the same test once more
    > > > > without your patches to see if I get the same pattern in freezes.
    > > >
    > > > I found some problems yesterday with mutex priority inheritance that
    > > > could potentially cause your freeze patterns.
    > > >
    > > > I will try to roll a preliminary patch as soon as the caffeine does its
    > > > magic.
    > >
    > > OK - here is a crude patch to fix some problems with mutex priority
    > > inheritance. My theory is that the clock thread gets stuck waiting on
    > > GIANT.
    > >
    > > During release/acquisition of a contested sleep mutex there are a few
    > > windows where a task can be preempted when actions (waking up blocked
    > > threads, ownership of the mutex, ..) need to be atomic as far as
    > > scheduling is concerned. Otherwise priority inheritance may fail. The
    > > patch uses critical_enter/critical_exit to protect these regions against
    > > preemption.
    > >
    > > It would be great if could run this in addition to the other patches.

    turnstile_claim() doesn't make any threads runnable and thus can't preempt.
    The other place is supposed to preempt, and it should be ok to do so. Note
    that since the turnstile chain lock is held, that includes a nested critical
    section and any preemption will be deferred until the turnstile lock is
    released via turnstile_release which happens in the middle of
    turnstile_unpend() after it has finished building a list of all the threads
    to be made runnable so that the turnstile object can be re-used safely. I
    don't think this patch will make much of a difference (if any). Can you
    provide a description of a case where you think the priority inheritance can
    fail if turnstile_unpend() doesn't run in a nested critical section? 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Daniel Eischen: "Re: sched_userret priority adjustment patch for sched_4bsd"

    Relevant Pages

    • Re: patch to make Linux capabilities into something useful (v 0.3.1)
      ... This is to make capabilities inheritable but don't add any others ... root privileges all the way, including in children processes - this is ... inheritance rules for capabilities which are closely modeled upon ... My patch doesn't change this behavior. ...
      (Linux-Kernel)
    • bonus inheritance
      ... Imagine an idle shell with max bonus, ... Draw to the center and have some inheritance. ... The second hunk of the 2.4 patch makes the bonus non-linear. ... The current tweaks in the scheduler ...
      (Linux-Kernel)