lkml.org 
[lkml]   [2004]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 4g/4g for 2.6.6
Rik van Riel <riel@redhat.com> wrote:
>
> On Tue, 25 May 2004, Rik van Riel wrote:
>
> > The point is, people like to run bigger workloads on
> > bigger systems. Otherwise they wouldn't bother buying
> > those bigger systems.
>
> Btw, you're right about the VMAs. Looking through customer
> stuff a bit more the more common issues are low memory being
> eaten by dentry / inode cache - which you can't always reclaim
> due to files being open, and don't always _want_ to reclaim
> because that could well be a bigger performance hit than the
> 4:4 split.

I did some testing a year or two back with the normal zone wound down to a
few hundred megs - filesytem benchmarks were *severely* impacted by the
increased turnover rate of fs metadata pagecache and VFS caches. I forget
the details, but it was "wow".

> The primary impact of the dentry / inode cache using memory
> isn't lowmem exhaustion, btw. It's lowmem fragmentation.
>
> Fragmentation causes fork trouble (gone with the 4k stacks)
> and trouble for the network layer and kiobuf allocation,
> which still do need higher order allocations.

I'm suspecting we'll end up needing mempools (or something) of 1- and
2-order pages to support large-frame networking. I'm surprised there isn't
more pressure to do something about this. Maybe people are increasing
min_free_kbytes.

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

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