Messages in this thread | | | Date | Wed, 10 Nov 1999 18:13:36 +0100 | From | Jamie Lokier <> | Subject | Re: 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/
| |