lkml.org 
[lkml]   [1999]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH 2.3.26: kmalloc GFP_ZERO
Andrea Arcangeli wrote:
> When you are I/O bound the page-fault rate is very very low and IMHO you
> are not going to see any sensitive improvement. clear page become a
> bottleneck only when the page fault rate is high.

Ah, but very shortly after you're I/O bound due to paging, there's
usually a need for lots of zero pages. This happens whenever any
program is started up. Why not spend the paging I/O time preparing
those zero pages?

> Actually on x86 doing it in software would be a bad idea anyway as
> currently there's no way to avoid cache pollution (and I don't have KNI
> here).

You can use MTRRs (probably too slow to set up), or there is a
page-table variation where the MTRR type bits can be encoded in the page
table bits (as fast as mapping a page, and I don't remember the
acronym). I think the latter predates KNI, so you might have it.

> I understand as I don't use -j5 either ;). I tune -j to make sure all CPUs
> are busy all the time and nothing more.

I do not have enough RAM for any value of -j to be perfect. I only have
64MB. Actually I get plenty of swapping with -j3 even on a 128MB
machine. Must be because I'm foolish enough to have a Netscape and an
Emacs running at the same time.

-- Jamie

-
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:54    [W:0.028 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site