Date: Mon, 27 Sep 2004 22:27:51 -0400 From: Stephan Uphoff <ups@tree.com> To: Julian Elischer <julian@elischer.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: sched_userret priority adjustment patch for sched_4bsd Message-ID: <1096338471.3733.254.camel@palm.tree.com> In-Reply-To: <41588FC5.6090203@elischer.org> References: <1096133353.53798.17613.camel@palm.tree.com> <200409271016.13345.jhb@FreeBSD.org> <1096305626.95152.163.camel@palm.tree.com> <200409271443.22667.jhb@FreeBSD.org><41588FC5.6090203@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096338471.3733.254.camel>