lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [showstopper] Memory leak in 2.2.1
Hi,

On Wed, Feb 03, 1999 at 02:14:40PM -0500, Alexander Viro wrote:

> What??? Wait... it's grow_inodes() and it looks like we never shrink the
> damned icache again. Looks like it was always so with possible exception

Does the explain the NTFS problems I was looking into? I'd noticed that
try_to_free_pages didn't do anything with the icache and in my innocence^W
ignorance, assumed that shrink_dcache_memory did something about it (maybe
I thought inodes weren't cached without a dentry or something).

> of 2.1.36-2.1.42 when we used slab instead of bare pages. Damn. It's not a
> leak per se - we just never shrink icache. Now, the fact that you managed

Out of curiosity, what was the reason behind not using the slab allocator?
I (think) I've noticed an interesting problem -- the slab allocator uses
page blocks of order > 0 for some caches, but get_free_pages only tries to
free single pages. As I can't think of a sane way to 'create' multi-page
blocks in gfp/try_to_free_page, maybe the slab allocator should reduce
the page block size it wants in low memory / fragmented memory situations.

Cheers,
Steve

--
If breastfeeding a pig is sickening to you, what the hell are you
doing on usenet? -- Aimee, on rec.music.tori-amos

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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