xfs-masters
[Top] [All Lists]

[xfs-masters] Re: 2.6.22-rc1-mm1

To: "David Chinner" <dgc@xxxxxxx>
Subject: [xfs-masters] Re: 2.6.22-rc1-mm1
From: "Michal Piotrowski" <michal.k.k.piotrowski@xxxxxxxxx>
Date: Tue, 22 May 2007 16:45:25 +0200
Cc: "Christoph Hellwig" <hch@xxxxxx>, xfs-masters@xxxxxxxxxxx, "Andrew Morton" <akpm@xxxxxxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VyUT18czMuTLOopQg1C6YvGgUjMv4vFNbQEOfhxGGRD/gQ7cW24NkwCqatUdBnJOL4RhS5z/gKkSx+ZA4VA3AgQz+uZjPHtmeeYRUQqYgdM5z2em3vbdUhK/Gw5j16g30nG0/6UDfHPJp3NLIj/npw1mt2t8RnYtjHEot3UNOm4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=haXRbfCJYXt8zJs0Y3qQJWXGhlqrkX2UboQfhcICGbV9TwtebdIwP5HyBLd+eUNu3L0YmPWxOrgJQPO8Wc05my7qDuPEIF28cFi8MFE9RN4TrT5h+EelJcM+UPLxM4UDEQ1FjiWqg5Oecyy0ZxUUr5NupsUeIfcfxSv1z/koyfg=
In-reply-to: <20070521101141.GX86004887@sgi.com>
References: <20070515201914.16944e04.akpm@linux-foundation.org> <464B304C.5040104@googlemail.com> <20070516094133.bec04e65.akpm@linux-foundation.org> <20070517020600.GS85884050@sgi.com> <20070517084135.GA8510@lst.de> <464CB577.5080106@googlemail.com> <20070518021114.GV86004887@sgi.com> <20070521101141.GX86004887@sgi.com>
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
Hi David,

On 21/05/07, David Chinner <dgc@xxxxxxx> wrote:
> On Fri, May 18, 2007 at 12:11:14PM +1000, David Chinner wrote:
> > On Thu, May 17, 2007 at 10:05:11PM +0200, Michal Piotrowski wrote:
> > > I applied your patch and I get another oops
> > >
> > > [  261.491499] XFS mounting filesystem loop0
> > > [  261.501641] Ending clean XFS mount for filesystem: loop0
> > > [  261.507698] SELinux: initialized (dev loop0, type xfs), uses xattr
> > > [  261.567441] XFS mounting filesystem loop0
> > > [  261.573931] allocation failed: out of vmalloc space - use 
> > > vmalloc=<size> to increase size.
> > > [  261.582935] xfs_buf_get_noaddr: failed to map pages
> > > [  261.592478] Ending clean XFS mount for filesystem: loop0
> > > [  261.618543] SELinux: initialized (dev loop0, type xfs), uses xattr
> > > [  261.691563] XFS mounting filesystem loop0
> > > [  261.698927] allocation failed: out of vmalloc space - use 
> > > vmalloc=<size> to increase size.
> > >                                   ^^^^^^^^^^^^^^^^^^^^
> > >                                   interesting
> >
> > Yeah, looks like a vmalloc leak is occurring. I haven't noticed
> > it before because:
> >
> > VmallocTotal: 137427898368 kB
> > VmallocUsed:   3128272 kB
> > VmallocChunk: 137424770048 kB
> >
> > It takes a long time to leak enough vmapped space to run out on ia64...
> >
> > That tends to imply we have a mapped buffer being leaked somewhere.
> > Interestingly, I don't see a memory leak so we must be freeing the
> > memory associated with the buffer, just not unmapping it first. Not
> > sure how that can happen yet.....
> .....
> >
> > Looks like we're leaking 272kB of vmalloc space on each mount/unmount
> > cycle. I'm trying to track this down now....
>
> I've found what is going on here - kmem_alloc() is decidedly more
> forgiving than manually built page arrays and vmap/vunmap. Prior
> to this change we wouldn't have even leaked memory....
>
> Christoph - this is an interaction with xfs_buf_associate_memory();
> I'm not sure what it is doing is at all safe now that it never gets
> passed kmem_alloc()d memory - it works for the log recovery case
> because we use it in pairs - once to shorten the buffer and then once
> to put it back the way it was.
>
> But that doesn't work for the log buffers (we never return them to their
> original state) and the log wrap case looks to work mostly by accident
> now (and could posibly lead to double freeing pages)....
>
> It seems that what we really need with the new code is a xfs_buf_clone()
> operation followed by trimming the range to what the secondary I/O needs
> to span. This would work for the log buffer case as well. Your thoughts?
>
> In the meantime, the following patch appears to fix the leak.

After a few minutes of mount/umount cycle everything seems to be ok,
problem fixed.

Thanks!

>
> Cheers,
>
> Dave.

Regards,
Michal

-- 
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)


<Prev in Thread] Current Thread [Next in Thread>