Re: sched_userret priority adjustment patch for sched_4bsd

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

  • Next message: Stephan Uphoff: "Re: scheduler (sched_4bsd) questions" 
    To: Julian Elischer <julian@elischer.org>
Date: Mon, 27 Sep 2004 22:27:51 -0400

    On Mon, 2004-09-27 at 18:10, Julian Elischer wrote:
    > Stephan Uphoff wrote:
    >
    > >On Mon, 2004-09-27 at 14:43, John Baldwin wrote:
    > >
    > >
    > >>>>@@ -272,7 +272,7 @@
    > >>>> {
    > >>>>
    > >>>> mtx_assert(&sched_lock, MA_OWNED);
    > >>>>- if (td->td_priority < curthread->td_priority)
    > >>>>+ if (td->td_priority < curthread->td_ksegrp->kg_user_pri)
    > >>>> curthread->td_flags |= TDF_NEEDRESCHED;
    > >>>> }
    > >>>>
    > >>>>
    >
    > in sched_userret() we do:
    > kg = td->td_ksegrp;
    > if (td->td_priority != kg->kg_user_pri) {
    > mtx_lock_spin(&sched_lock);
    > td->td_priority = kg->kg_user_pri;
    > mtx_unlock_spin(&sched_lock);
    > }
    >
    > but we don't actually take any action in the case where the thread is
    > heading out to userland with
    > a priority of less importance than a waiting thread. That happens in
    > AST() where we also set it down
    > but only in the case of TDF_NEEDRESCHED being set.
    >
    > it would make more sense to ALWAYS to the TDF_NEEDRESCHED clause, in
    > userret()
    > based on the user priority... i.e. the priority would be reduced going
    > to userland.
    > Unfortunatly this would stop one of the reasons to for priorityu
    > raisning in BSD.
    >
    > The priority of a thread that waits for IO is raised not only to make it
    > start again in the kernel
    > as an interactive thread, but also so that it can run into userland too
    > and get some priority
    > for actually USING the new data/input..

    Thanks - I wasn't aware of this.
    Isn't there a high potential for abuse?
    A client/server programs constantly refreshing priority by waiting for
    requests/replies comes to mind. If a client/server pair constantly talks
    to each other they could eat a lot of cpu time.
    I have to think about this some more.

            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: Stephan Uphoff: "Re: scheduler (sched_4bsd) questions"

    Relevant Pages