Re: The performance and behaviour of the anti-fragmentation relatedpatches

[Andrew Morton]

On Fri, 02 Mar 2007 12:43:42 -0500
Rik van Riel <riel@xxxxxxxxxx> wrote:

> Andrew Morton wrote:
> > On Fri, 2 Mar 2007 09:23:49 -0800 (PST) Christoph Lameter <clameter@xxxxxxxxxxxx> wrote:
> > 
> >> On Fri, 2 Mar 2007, Andrew Morton wrote:
> >>
> >>>> Linux is *not* happy on 256GB systems.  Even on some 32GB systems
> >>>> the swappiness setting *needs* to be tweaked before Linux will even
> >>>> run in a reasonable way.
> >>> Please send testcases.
> >> It is not happy if you put 256GB into one zone.
> > 
> > Oh come on.  What's the workload?  What happens?  system time?  user time?
> > kernel profiles?
> 
> I can't share all the details, since a lot of the problems are customer
> workloads.
> 
> One particular case is a 32GB system with a database that takes most
> of memory.  The amount of actually freeable page cache memory is in
> the hundreds of MB.

Where's the rest of the memory? tmpfs?  mlocked?  hugetlb?

>   With swappiness at the default level of 60, kswapd
> ends up eating most of a CPU, and other tasks also dive into the pageout
> code.  Even with swappiness as high as 98, that system still has
> problems with the CPU use in the pageout code!
> 
> Another typical problem is that people want to back up their database
> servers.  During the backup, parts of the working set get evicted from
> the VM and performance is horrible.

userspace fixes for this are far, far better than any magic goo the kernel
can implement.  We really need to get off our butts and start educating
people.

> A third scenario is where a system has way more RAM than swap, and not
> a whole lot of freeable page cache.  In this case, the VM ends up
> spending WAY too much CPU time scanning and shuffling around essentially
> unswappable anonymous memory and tmpfs files.

Well we've allegedly fixed that, but it isn't going anywhere without
testing.


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