Messages in this thread | | | From | Neil Brown <> | Date | Thu, 25 Nov 2004 11:14:39 +1100 | Subject | Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs |
| |
On Wednesday November 24, akpm@osdl.org wrote: > Neil Brown <neilb@cse.unsw.edu.au> wrote: > > > > Would the following (untested-but-seems-to-compile - > > explanation-of-concept) patch be at all reasonable to avoid stack > > depth problems with stacked block devices, or is adding stuff to > > task_struct frowned upon? > > It's always a tradeoff - we've put things in task_struct before to get > around sticky situations. Certainly, removing potentially unbounded stack > utilisation is a worthwhile thing to do. > > The patch bends my brain a bit.
Recursion is like that (... like recursion, that is :-).
> Shouldn't the queueing happen in > submit_bio()?
Both md and dm call generic_make_request rather than submit_bio to start IO on slaves, so it wouldn't work in submit_bio. If dm and md were changes to use submit_bio, then the counts (page-in, page-out) would be quite different...
> > Is bi_next free in there? If anyone tries to do synchronous I/O things > will get stuck.
It is my understanding the bi_next is free. It is available for use by ->make_request_fn and below. __make_request uses it for chaining bio's together into a request. raid5 uses it for other things.
If a ->make_request_fn did synchronous IO things would definitely get unstuck. But I don't think they should and doubt if they do (md certainly doesn't).
NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |