Date: Thu, 20 Dec 2001 13:56:57 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Julian Elischer <julian@elischer.org>, arch@FreeBSD.org, Alfred Perlstein <bright@mu.org> Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <XFMail.011220135657.jhb@FreeBSD.org> In-Reply-To: <3149.1008883923@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Dec-01 Poul-Henning Kamp wrote: > In message <XFMail.011220132124.jhb@FreeBSD.org>, John Baldwin writes: > >>> Now the two requests have been reordered without any of the modules >>> having any hint of this. >>> >>> The obvious ways to fix this is to continue to queue once you queue >>> on a module (in other words: always queue if the queue is non-empty) >> >>Hmm, I was thinking that the original request would block when it queued the >>request, and would be woken up when the original request was completed by the >>worker thread. Thus, for each producer, only one item should be in the queue >>at a time (plus any sub events it may create), but that multiple producers >>may >>be putting events onto the queue handled by the worker thread. > > Ahh, but here you run into the zig-zag thing we two have talked about > earlier: what if I am running in an interrupt thread at this time ? > > This could be an incoming packet which triggers an outgoing response > or this could be a disk-write complete which triggers the write of > the other copy in the mirror. > > You cannot expect to be moving uniformly up (or down) the tree in > these kinds of layers so sleeping would be bad, and as far as my > intuition tells me, could lead to starvation and deadlock. Interrupts answer requests from the top half, they don't initiate requests on their own AFAIK. If an interrupt needs to initiate a request that it wants return state on, that's a bug I think. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220135657.jhb>