lkml.org 
[lkml]   [1998]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.105 MASSIVE memory leak (mmap_104-patch)
On Mon, 8 Jun 1998, Bill Hawes wrote:

> Michael L. Galbraith wrote:
>
> > I let it continue to grind until 13:30 before killing everything via
> > an rlogin from the laptop. I then ran a Bonnie -s 100 to flush the
> > system, and discovered that I had 64Mb still tied up afterward, whereas
> > normally it's only 6-7Mb. I took it down to single user and repeated
> > the Bonnie to no effect.
>
> Hi Mike,
>
> Glad to see you're up to your stress-testing again. I'm not aware of any memory leak problems in the
> patches I've posted, but please do run the leak detector and report the findings.
>

Hi Bill,

The leaked memory seems to be 'extra' from the mmap_104-patch. Reversing
the patch cleared the leak.

+ /*
+ * We need at least one vma, and may need an extra one if we
+ * unmap a hole. Get them now before acquiring the semaphore.
+ */
+ error = -ENOMEM;
+ vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
+ if (!vma)
+ goto out;
+ extra = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
+ /* (allocation will be checked later) */
+

637339 mmap.c:207
2083 buffer.c:1219
2079 buffer.c:1601
1499 file_table.c:92
625 nfscache.c:285
460 nfsfh.c:207
317 filemap.c:852
256 inode.c:415
226 dcache.c:468
225 dcache.c:464
219 filemap.c:291
185 mmap.c:204
...

Cheers,

-Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.139 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site