Date: Tue, 21 Sep 2004 13:41:08 -0400 From: Stephan Uphoff <ups@tree.com> To: Julian Elischer <julian@elischer.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <1095788468.53798.92.camel@palm.tree.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1095788468.53798.92.camel>