cvs commit: src/sys/geom/raid3 g_raid3.c

Ruslan Ermilov ru at freebsd.org
Thu Mar 9 13:36:30 PST 2006


On Thu, Mar 09, 2006 at 01:55:51PM -0700, Scott Long wrote:
> Ruslan Ermilov wrote:
> >On Thu, Mar 09, 2006 at 01:57:21PM -0500, Brian Fundakowski Feldman wrote:
> >
> >>On Tue, Mar 07, 2006 at 02:32:00PM +0100, Pawel Jakub Dawidek wrote:
> >>
> >>>On Mon, Mar 06, 2006 at 07:39:11PM -0500, Brian Fundakowski Feldman 
> >>>wrote:
> >>>+> On Wed, Feb 22, 2006 at 10:21:05AM +0000, Pawel Jakub Dawidek wrote:
> >>>+> > pjd         2006-02-22 10:21:05 UTC
> >>>+> > 
> >>>+> >   FreeBSD src repository
> >>>+> > 
> >>>+> >   Modified files:
> >>>+> >     sys/geom/raid3       g_raid3.c 
> >>>+> >   Log:
> >>>+> >   Do not use bio structure after g_io_deliver(), it may not longer 
> >>>by valid.
> >>>+> >   
> >>>+> >   Found and fixed by:     Vsevolod Lobko <seva at ip.net.ua>
> >>>+> >   MFC after:              3 days
> >>>+> 
> >>>+> I actually found and fixed it half a year ago... could you please
> >>>+> integrate the rest of the fixes from my changes back then?  A
> >>>+> short-term low-memory deadlock is still possible (observed in
> >>>+> practice).  I think the changes also improve readability -- see
> >>>+> for example the reason r1.46 existed.
> >>>
> >>>Heh. I own you apology. I haven't had time to work on graid3 back then
> >>>and I also overlooked fix of this very problem.
> >>>
> >>>I integrated you fixes to my last patch which I'm planning to commit
> >>>after receiving some feedback:
> >>>
> >>>	http://people.freebsd.org/~pjd/patches/graid3.patch
> >>
> >>Everything seems good to go, running -CURRENT's graid3 + these changes
> >>on 6-STABLE; are there particular areas where you think I should try
> >>testing for improved performance?
> >>
> >
> >I was fighting a problem today when our geom_cache attempts to fill
> >256K of bio_data coming from graid3, and this obviously fails because
> >graid3 only allocates memory for first 64k from its 64k UMA zone.
> >This patch doesn't fix this problem.  I have MAXPHYS bumped to 512K,
> >which is important to reproduce the problem.  Can you please fix this?
> >Temporarily, I've added 128/256/512 zones to satisfy my needs.
> >
> >
> >Cheers,
> 
> MAXPHYS was never meant to go above 128K.  You'll run a very real risk 
> of exhausting KVA under load.  And, all block drivers for the past 10 
> years have been written with the assumption that MAXPHYS will never be
> above 128K.  In other words, don't shoot yourself in the foot and then
> cry that it hurts =-)
> 
We've fixed some defines that abused MAXPHYS to mean 64k.  I'm compiling
the kernel with default MAXPHYS now, but still, there's no 128k zone in
graid3 to allocate from.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060309/dce4540c/attachment.bin


More information about the cvs-src mailing list