Date: Wed, 26 Jan 2011 09:26:26 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-projects@freebsd.org, Alexander Motin <mav@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r217828 - projects/graid/head/sys/geom/raid Message-ID: <alpine.BSF.2.00.1101260923140.44308@fledge.watson.org> In-Reply-To: <201101251117.49069.jhb@freebsd.org> References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <201101251117.49069.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Jan 2011, John Baldwin wrote: > Hmm, so this allocates bio's to make the dump work. I believer other dump > routines in other drivers do not do this, but instead use pre-allocated > commands to schedule dump I/O requests. Would it be possible to > pre-allocate the bio that is used here when dumping is enabled and reuse it > for each g_raid_dump() call without free'ing it when the I/O is finished? Yeah, same concern here: memory allocation and freeing in the dump path leads to less robustness. Part of why the existing geom/dump interaction was so simplistic was to avoid exactly this problem by not needing lots of bio allocaiton/replication/etc on the way up/down the stack. Likewise, the goal was to minimise dependence on correct operation of the kernel scheduler. Some storage device drivers are poorly behaved in this regard, but introucing new dependencies in the stack just makes it harder to fix those drivers. (A similar discussion is taking place in the context of network dumping, where it's really important not to introduce further large kernel subsystem dependencies: you want debugging paths to depend on as little in the way of sensitive global data structures, locks, etc, as possible.) Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101260923140.44308>