From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 17:41:11 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 9062516A4CF for ; Tue, 21 Sep 2004 17:41:11 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 1367B43D3F for ; Tue, 21 Sep 2004 17:41:11 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 12993 invoked by uid 89); 21 Sep 2004 17:41:10 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 21 Sep 2004 17:41:10 -0000 Received: (qmail 12970 invoked by uid 89); 21 Sep 2004 17:41:09 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 21 Sep 2004 17:41:09 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8LHf8mt059050; Tue, 21 Sep 2004 13:41:09 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <414F7DA3.6090409@elischer.org> References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> <414F7DA3.6090409@elischer.org> Content-Type: text/plain Message-Id: <1095788468.53798.92.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 13:41:08 -0400 Content-Transfer-Encoding: 7bit cc: John Baldwin 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: Tue, 21 Sep 2004 17:41:11 -0000 On Mon, 2004-09-20 at 21:02, Julian Elischer wrote: > > > > > >On Sunday 19 September 2004 03:10 am, Julian Elischer wrote: > > > > > >>John Baldwin wrote: > >> > >> > >>>On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > >>> > >>> > >>>>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > >>>> > >>>> > >>>>>Stephan Uphoff wrote: > >>>>> > >>>>> > >>>>>>If this is true kernel threads can be preempted while holding > >>>>>>for example the root vnode lock (or other important kernel > >>>>>>resources) while not getting a chance to run until there are no more > >>>>>>user processes with better priority. > >>>>>> > >>>>>> > >>>>>This is also true, though it is a slightly more complicated thing than > >>>>>that. > >>>>>Preempting threads are usually interrupt threads and are thus usually > >>>>>short lived,. > >>>>> > >>>>> > >>>>But interrupt threads often wake up other threads ... > >>>> > >>>> > >>>That are lower priority and thus won't be preempted to. Instead, they > >>>run when the interrupt thread goes back to sleep after it finishes. > >>> > >>> > >>though that may still be before the original preempted thread gets run.. > >> > >>that reminds me.. > >>John, we should add a flag to setrunqueue to add a preempted thread back at > >>the FRONT of it's runqueue.. So that it gets a chance to use the rest of > >>its slot.. > >> > >> > > > >The scheduler can already detect this by noting that curthread is being passed > >to sched_add() when it has quantum left and then put it at the head of the > >queue for its priority but only with the remaining quanta. This only really > >works for schedulers that actually track quanta, i.e., not 4BSD. Given that, > >I think the scheduler is free to implement this how it chooses and doesn't > >require another flag to setrunqueue(). > > > > Just for kicks I implemented this in my p4 branch to see if it would help the problem > with atapi cdroms failing to work when premption is turned on.. > > but it didn't help.. > > (it's a very strange problem.. turning on preemption makes my test machine's cdrom > time out so much in boot that it takes 5 minutes to probe during boot.) Great news ! - I actually switched target machines just when this started to happen and thought the cdrom of the new target was bad and disconnected it ;-) I reconnected it this morning and did a little debugging. Looks like an interrupt race condition in the ata code. Can you try the following patch? Stephan Index: sys/dev/ata/ata-lowlevel.c =================================================================== RCS file: /cvsroot/src/sys/dev/ata/ata-lowlevel.c,v retrieving revision 1.47 diff -u -r1.47 ata-lowlevel.c --- sys/dev/ata/ata-lowlevel.c 3 Sep 2004 12:10:44 -0000 1.47 +++ sys/dev/ata/ata-lowlevel.c 21 Sep 2004 17:36:27 -0000 @@ -88,11 +88,15 @@ (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE))) request->flags &= ~ATA_R_DMA; + ch->running = request; + switch (request->flags & (ATA_R_ATAPI | ATA_R_DMA)) { /* ATA PIO data transfer and control commands */ default: { + + /* record command direction here as our request might be gone later */ int write = (request->flags & ATA_R_WRITE); @@ -136,7 +140,7 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; /* ATA DMA data transfer commands */ @@ -167,7 +171,7 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + //ch->running = request; return ATA_OP_CONTINUES; /* ATAPI PIO commands */ @@ -192,7 +196,7 @@ /* command interrupt device ? just return and wait for interrupt */ if ((request->device->param->config & ATA_DRQ_MASK) == ATA_DRQ_INTR) { - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; } @@ -226,7 +230,7 @@ ATA_PROTO_ATAPI_12 ? 6 : 8); /* record the request as running and return for interrupt */ - ch->running = request; + //ch->running = request; return ATA_OP_CONTINUES; case ATA_R_ATAPI|ATA_R_DMA: @@ -292,9 +296,11 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; } + + ch->running = NULL; /* request finish here */ if (ch->dma && ch->dma->flags & ATA_DMA_LOADED)