From owner-freebsd-arch@FreeBSD.ORG Mon Sep 27 13:05:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5862916A4CE for ; Mon, 27 Sep 2004 13:05:08 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C417B43D39 for ; Mon, 27 Sep 2004 13:05:07 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8RD54Bw022815; Mon, 27 Sep 2004 09:05:04 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8RD54U5022814; Mon, 27 Sep 2004 09:05:04 -0400 (EDT) (envelope-from green) Date: Mon, 27 Sep 2004 09:05:03 -0400 From: Brian Fundakowski Feldman To: Stephan Uphoff Message-ID: <20040927130503.GD1164@green.homeunix.org> References: <1095468747.31297.241.camel@palm.tree.com> <1095529353.31297.1192.camel@palm.tree.com> <1096135220.53798.17754.camel@palm.tree.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096135220.53798.17754.camel@palm.tree.com> User-Agent: Mutt/1.5.6i cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 13:05:08 -0000 On Sat, Sep 25, 2004 at 02:00:20PM -0400, Stephan Uphoff wrote: > On Sat, 2004-09-18 at 13:42, Stephan Uphoff wrote: > > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > > Stephan Uphoff wrote: > > > >I am also stomped by the special case of adding a thread X with better > > > >priority than the current thread to the runqueue if they belong to the > > > >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings > > > >might be zero and setrunqueue() will not call sched_add(). > > > >Because of this it looks like the current thread will neither be > > > >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the > > > >kernel boundary. > > > >This situation should resolve itself at the next sched_switch - however > > > >this might take a long time. (Especially if essential interrupt threads > > > >are blocked by mutexes held by thread X) > > > > > > > > > > you are correct. I am not yet preempting a running thread with a lesser > > > priority if they are siblings > > > (unless there is a slot available) Thsi is not becasue I don't want to > > > do it, but simply because it has not been done yet.. > > > we did have NO preemption, so having "some" preemption is still better > > > than where we were. > > > Special case code to check curthread for a preemption could be done but > > > at the moment the decision code for > > > whether to preempt or not is in maybe_preempt() and I don't want to > > > duplicate that. it is on th edrawing board though. > > > The other thing is, that even if we should be able to preempt a running > > > thread, there is no guarantee that it is on THIS > > > CPU. It may be on another CPU and that gets nasty in a hurry. > > > > Yes .. this could get nasty. > > This happens when the thread is bound to another cpu or someone changed > > thr_concurrency - otherwise the current thread must be a sibling right ? > > > > Maybe something brutal like: > > if ((curthread->td_ksegrp == kg) && > > (td->td_priority > curthread->td_priority)) > > curthread->td_flags |= TDF_NEEDRESCHED; > > > > in setrunqueue for > > the else case of "if (kg->kg_avail_opennings > 0)" > > would do the trick (without preemption) for the easy but probably more > > common cases? > > > > Maybe I can find some time next week to think about a clean > > fix. I find it always helpful having a small task in mind while reading > > source code. > > I wrote a fix that should cover all cases. > However I would like to test it a little bit before posting the patch. > Is there any multi-threaded kernel torture program that you can > recommend? It wasn't particularly designed as such but the utility in the src/tools/regression/gaithrstress/ directory is very quick at provoking thread/SMP/scheduler bugs if you give it a high thread count (and use a pretty fast DNS, I suppose). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\