Re: HIGHMEM4G config for 1GB RAM on desktop?

From: Marc-Christian Petersen
Date: Wed Aug 04 2004 - 14:27:00 EST


On Wednesday 04 August 2004 21:06, Andrew Morton wrote:

Hi Andrew,

> The 896M/128M split has a bit of a problem now each zone has its own LRU:
> the size of the highmem zone is less than the amount of memory which is
> described by the default /proc/sys/vm/dirty_ratio. So it is easy to
> completely fill highmem with dirty pages. This causes a fairly large
> amount of writeback via vmscan.c's writepage(). This causes poor I/O
> submission patterns. This causes a simple large, linear `dd' write to run
> at only 50-70% of disk bandwidth. (This was 6-12 months ago - it might be
> a bit better now)
> But I seem to be the only person who has noticed this yet ;) A workaround
> is to decrease dirty_ratio and dirty_background_ratio.

hmm, never tested to change the split with 2.6.x, but on 2.4 I didn't notice
any disk i/o regressions. Maybe due to a different VM ;)


> Decreasing PAGE_OFFSET as above is attractive, but I believe 0xc0000000 is
> part of the ABI, and although we know (from the 4g/4g and other such
> patches) that everything will work OK, I wonder if it's really worth doing,
> especially as it's a compile-time thing.

> But hey, if someone can identify specific benefits from it then perhaps
> sneaking in a config option, or maintaining an external patch would be
> worthwhile.

Maybe we can introduce something like 3.5GB patch like 2.4-aa and 2.4-wolk
has? For reference:

http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23aa3/00_3.5G-address-space-5

Let me know and I'll cook up a 2.6 version.

Grmpf, that reminds me of my Documentation cleanup patches ;(

ciao, Marc
-
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/