Date: Mon, 04 Oct 2004 14:26:23 -0400 From: Stephan Uphoff <ups@tree.com> To: John Baldwin <jhb@FreeBSD.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: sched_switch (sched_4bsd) may be preempted Message-ID: <1096914383.44307.25.camel@palm.tree.com> In-Reply-To: <200410041321.45142.jhb@FreeBSD.org> References: <1096610130.21577.219.camel@palm.tree.com> <200410041321.45142.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2004-10-04 at 13:21, John Baldwin wrote:
> On Friday 01 October 2004 01:55 am, Stephan Uphoff wrote:
> > sched_switch (sched_4bsd) may be preempted in setrunqueue or slot_fill.
> > This could be ugly.
> > Wrapping it into a critical section and resetting TDP_OWEPREEMPT should
> > work.
> >
> > Hand trimmed patch:
> >
> > RCS file: /cvsroot/src/sys/kern/sched_4bsd.c,v
> > retrieving revision 1.65
> > diff -u -r1.65 sched_4bsd.c
> > --- sys/kern/sched_4bsd.c 16 Sep 2004 07:12:59 -0000 1.65
> > +++ sys/kern/sched_4bsd.c 1 Oct 2004 05:35:28 -0000
> > @@ -823,6 +823,7 @@
> > TD_SET_CAN_RUN(td);
> > else {
> > td->td_ksegrp->kg_avail_opennings++;
> > + critical_enter();
> > if (TD_IS_RUNNING(td)) {
> > /* Put us back on the run queue (kse and all).
> > */
> > setrunqueue(td, SRQ_OURSELF|SRQ_YIELDING);
> > @@ -834,6 +835,8 @@
> > */
> > slot_fill(td->td_ksegrp);
> > }
> > + critical_exit();
> > + td->td_pflags &= ~TDP_OWEPREEMPT;
> > }
> > if (newtd == NULL)
> > newtd = choosethread();
>
> I thought that SRQ_YIELDING turned preempting off already.
Thanks - I missed that for setrunqueue.
However it is needed for maybe_preempt_in_ksegrp and slot_fill.
Guess adding a flag parameter and checking for SRQ_YIELDING for both
would be and easy way to get rid of the critical section hack.
Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096914383.44307.25.camel>