Re: scheduler (sched_4bsd) questions

From: Stephan Uphoff (ups_at_tree.com)
Date: 09/18/04

  • Next message: John Baldwin: "Re: scheduler (sched_4bsd) questions" 
    To: Julian Elischer <julian@elischer.org>
Date: Sat, 18 Sep 2004 13:42:33 -0400

    On Fri, 2004-09-17 at 21:20, Julian Elischer wrote:
    > Stephan Uphoff wrote:
    > >
    > >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,.

    But interrupt threads often wake up other threads ...

    >
    >
    > The theory is however that as long as the CPU is doing something, teh
    > throughput is
    > still being maintianed.

    Mhhh .. yes - I guess the only problem is with pathetic cases. ( Tons of
    cpu bound threads and nice values that prevent the preempted thread to
    gain a better priority)

    > (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 :-)

    Great

    > >
    > >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.

    Yes .. this could get nasty.
    This happens when the thread is bound to another cpu or someone changed
    thr_concurrency - otherwise the current thread must be a sibling right ?

    Maybe something brutal like:
            if ((curthread->td_ksegrp == kg) &&
               (td->td_priority > curthread->td_priority))
                    curthread->td_flags |= TDF_NEEDRESCHED;

    in setrunqueue for
    the else case of "if (kg->kg_avail_opennings > 0)"
    would do the trick (without preemption) for the easy but probably more
    common cases?

    Maybe I can find some time next week to think about a clean
    fix. I find it always helpful having a small task in mind while reading
    source code.

    > >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..

    But there is a huge difference between thinking about a little vacuuming
    and wishing for some bulldozers ;-)

    > what version are you reading? -current?
    current (Sep 16)

    Thanks for the detailed answer.

            Stephan

    _______________________________________________
    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: John Baldwin: "Re: scheduler (sched_4bsd) questions"

    Relevant Pages