[lkml]   [2001]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch][rfc][rft] vm throughput 2.4.2-ac4
On 1 Mar 2001, Linus Torvalds wrote:
> In article <Pine.LNX.4.33.0103011747560.1961-100000@duckman.distro.conectiva>,
> Rik van Riel <> wrote:
> >
> >I haven't tested it yet for a number of reasons. The most
> >important one is that the FreeBSD people have been playing
> >with this thing for a few years now and Matt Dillon has
> >told me the result of their tests ;)
> Note that the Linux VM is certainly different enough that I
> doubt the comparisons are all that valid. Especially actual
> virtual memory mapping is basically from another planet
> altogether, and heuristics that are appropriate for *BSD may not
> really translate all that better.

The main difference is that under Linux the size of the
inactive list is dynamic, while under FreeBSD the system
always tries to keep a (very) large inactive list around.

I'm not sure if, or how, this would influence the percentage
of dirty pages on the inactive list or how often we'd need to
flush something to disk as opposed to reclaiming clean pages.

> I'll take numbers over talk any day. At least Mike had numbers,

The only number I saw when reading over this thread was that
Mike found that under one workload he tested the Linux kernel
ended up doing IO anyway about 2/3rds of the time.

This would also mean we'd be able to _avoid_ IO 1/3rd of the
time ;)

> In short, please don't argue against numbers.

I'm not arguing against his numbers, all I want to know is
if the patch has the same positive effect on other workloads
as well...


Linux MM bugzilla:

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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