Re: scheduler (sched_4bsd) questions

From: Julian Elischer (julian_at_elischer.org)
Date: 09/18/04

  • Next message: Christian Weisgerber: "Re: diff(1)" 
    Date: Fri, 17 Sep 2004 18:20:30 -0700
To: Stephan Uphoff <ups@tree.com>

    Stephan Uphoff wrote:

    >Hi,
    >
    >I finally found some time to take a peek at the sched_4bsd scheduler
    >and found two things I could not explain:
    >
    >It looks like the thread priority of a thread in the kernel is normally
    >its user priority.
    >( Unless it slept with priority change or due to mutex priority
    >inheritance)
    >

    exactly.

    >
    >If this is true kernel threads can be preempted while holding
    >for example the root vnode lock (or other important kernel
    >resources) while not getting a chance to run until there are no more
    >user processes with better priority.
    >

    This is also true, though it is a slightly more complicated thing than
    that.
    Preempting threads are usually interrupt threads and are thus usually
    short lived,.

    The theory is however that as long as the CPU is doing something, teh
    throughput is
    still being maintianed. (For this reason we have not worked on the
    problem you mention yet, though
    it will eventually get to the top of someone's list :-)
    .

    >I am probably missing a priority adjustment on kernel entry somewhere
    >but seem to be unable to find it :-(
    >

    >
    >I am also stomped by the special case of adding a thread X with better
    >priority than the current thread to the runqueue if they belong to the
    >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings
    >might be zero and setrunqueue() will not call sched_add().
    >Because of this it looks like the current thread will neither be
    >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the
    >kernel boundary.
    >This situation should resolve itself at the next sched_switch - however
    >this might take a long time. (Especially if essential interrupt threads
    >are blocked by mutexes held by thread X)
    >

    you are correct. I am not yet preempting a running thread with a lesser
    priority if they are siblings
    (unless there is a slot available) Thsi is not becasue I don't want to
    do it, but simply because it has not been done yet..
    we did have NO preemption, so having "some" preemption is still better
    than where we were.
     Special case code to check curthread for a preemption could be done but
    at the moment the decision code for
    whether to preempt or not is in maybe_preempt() and I don't want to
    duplicate that. it is on th edrawing board though.
    The other thing is, that even if we should be able to preempt a running
    thread, there is no guarantee that it is on THIS
    CPU. It may be on another CPU and that gets nasty in a hurry.

    >
    >Thanks in advance for any hints.
    >
    > Stephan
    >
    >PS: I am impressed how clean and easy to read the scheduler sources are.
    > Looks like a lot of hard work went into this.
    >

    There is a lot to clean up yet..
    what version are you reading? -current?

    >
    >_______________________________________________
    >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"
    >
    >

    _______________________________________________
    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: Christian Weisgerber: "Re: diff(1)"

    Relevant Pages