From owner-freebsd-current@FreeBSD.ORG Mon Jan 18 07:06:52 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 B4F701065692 for ; Mon, 18 Jan 2010 07:06:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 458948FC17 for ; Mon, 18 Jan 2010 07:06:51 +0000 (UTC) Received: by fxm27 with SMTP id 27so1933250fxm.3 for ; Sun, 17 Jan 2010 23:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=qpwKPMuLrYF9KI0tjRzA69CZc4o2EfuSzmxzSv9IY7A=; b=IC0WXojG8WFZaMWFfDxkoOi+lnXtSyWzVAAiwg+DQhUMaVPgJxEbKplaFayq9sOsmo jxUFDIcYU1nlvSKAtg5mNEzq4rr+yHEi/xP0MRMIO0C4LJmsKgkowunthEDlYM4Mokfv eWFP8pilV29wrCbCbpEBh5p0SktYWYgQWQb80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bBm63vD09zSvRP3CuGa9JaFHWKLWkFTNgYn+8Iw+OrxYwe2ECZez+RJW+IVOpm37+B dKQ1e42AQLKPMqw9n1/KR8i04GeWR7yhGq22hHJJKJ5HJRuPx55W2N+e94ZHFXd7oDRn H+l4ccu93wwfZg2bXOARS4OsieZpp9F3i1ytE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.143.82 with SMTP id t18mr7040790fau.52.1263798411213; Sun, 17 Jan 2010 23:06:51 -0800 (PST) In-Reply-To: <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> References: <20100117.142200.321689433999177718.okuno.kohji@jp.panasonic.com> <20100117.152835.119882392487126976.okuno.kohji@jp.panasonic.com> <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> Date: Mon, 18 Jan 2010 08:06:51 +0100 X-Google-Sender-Auth: 90acd4bdead2b246 Message-ID: <3bbf2fe11001172306m69ff6544i3aaf05e2540136e1@mail.gmail.com> From: Attilio Rao To: Kohji Okuno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, jroberson@jroberson.net Subject: Re: Bug about sched_4bsd? 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: Mon, 18 Jan 2010 07:06:52 -0000 2010/1/18 Kohji Okuno : > Hello, > > Thank you, Attilio. > I checked your patch. I think that your patch is better. > I tested the patch quickly, and I think it's OK. > # This probrem does not occur easily :-< > > > What do you think about maybe_resched()? > I have never experienced about maybe_resched(), but I think that the > race condition may occur. > > <> > sched_4bsd.c: =C2=A0 =C2=A0 maybe_resched() > sched_4bsd.c: =C2=A0 =C2=A0 resetpriority_thread() > sched_4bsd.c: =C2=A0 =C2=A0 sched_nice() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get thread_lock(td) > kern_resource.c: =C2=A0donice() > kern_resource.c: =C2=A0setpriority() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 get PROC_LOCK() > > static void > maybe_resched(struct thread *td) > { > =C2=A0 =C2=A0 =C2=A0 =C2=A0THREAD_LOCK_ASSERT(td, MA_OWNED); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (td->td_priority < curthread->td_priority) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0curthread->td_flag= s |=3D TDF_NEEDRESCHED; > } > > I think, when td->td_lock is not &sched_lock, curthread->td_lock is > not locked in maybe_resched(). I didn't look closely to the maybe_resched() callers but I think it is ok. The thread_lock() function works in a way that the callers don't need to know which container lock is present in a particular moment, there is always a guarantee that the contenders will spin if the lock on the struct can't be held. In the case you outlined something very particular was happening. Basically, we get &sched_lock but sched_lock was not the lock present on td_lock. That means all the other paths willing to access to td_lock for that thread (via thread_lock()) were allowed to do that even if we wanted to keep the critical path closed. Attilio --=20 Peace can only be achieved by understanding - A. Einstein