From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 22:10:46 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFB010656CC for ; Thu, 26 Aug 2010 22:10:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 808A88FC0A for ; Thu, 26 Aug 2010 22:10:45 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA06779; Fri, 27 Aug 2010 01:10:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ookeg-000Pj7-Ob; Fri, 27 Aug 2010 01:10:42 +0300 Message-ID: <4C76E661.60600@icyb.net.ua> Date: Fri, 27 Aug 2010 01:10:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <201008261649.20543.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:10:46 -0000 on 27/08/2010 00:20 mdf@FreeBSD.org said the following: > > I tried making sched_pin() a real function which used > intr_disable/intr_restore around saving off td->td_oncpu, > td->td_lastcpu and ts->ts_cpu, and the stack at the time of call. In > sched_switch when I saw an unexpected migration I printed all that > out. I found that on my boxes, at sched_pin() time ts_cpu was already > different from td->td_oncpu, so the specific problem I was having was > that while another thread can change ts_cpu it has no way to force > that thread to immediately migrate. Like e.g. in sched_affinity where ts_cpu is first changed and then the old cpu is ipi-ed? > I believe the below patch fixes the issue, though I'm open to other methods: > > > Index: kern/sched_ule.c > =================================================================== > --- kern/sched_ule.c (.../head/src/sys) (revision 158279) > +++ kern/sched_ule.c (.../branches/BR_BUG_67957/src/sys) (revision 158279) > @@ -112,6 +112,7 @@ > /* flags kept in ts_flags */ > #define TSF_BOUND 0x0001 /* Thread can not migrate. */ > #define TSF_XFERABLE 0x0002 /* Thread was added as transferable. */ > +#define TSF_BINDING 0x0004 /* Thread is being bound. */ I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is not sufficient in this case? -- Andriy Gapon