Re: More info: 2.1.108 page cache performance on low memory

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On 20 Jul 1998 11:15:12 +0200, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
said:

> I don't know if its easy, but we probably should get rid of buffer
> cache completely, at one point in time. It's hard to balance things
> between two caches, not to mention other memory objects in kernel.

No, we need the buffer cache for all sorts of things.  You'd have to
reinvent it if you got rid of it, since it is the main mechanism by
which we can reliably label IO for the block device driver layer, and we
also cache non-page-aligned filesystem metadata there.

> Then again, I have made some changes that make my system very stable
> wrt memory fragmentation:

> #define SLAB_MIN_OBJS_PER_SLAB  1
> #define SLAB_BREAK_GFP_ORDER    1

The SLAB_BREAK_GFP_ORDER one is the important one on low memory
configurations.  I need to use this setting to get 2.1.110 to work at
all with NFS in low memory.

> I discussed this privately with slab maintainer Mark Hemment, where
> he pointed out that with this setting slab is probably not as
> efficient as it could be. Also, slack is bigger, obviously.

Correct, but then the main user of these larger packets is networking,
where the memory is typically short lived anyway.

> But system is much more stable, and it is now very *very* hard to get
> that annoying "Couldn't get a free page..." message than before (with
> default setup), when it was as easy as clicking a button in the
> Netscape.

I can still reproduce it if I let the inode cache grow too large: it
behaves really badly and seems to lock up rather a lot of memory.  Still
chasing this one; it's a killer right now.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org