From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@osdl.org>, Jens Axboe <axboe@suse.de>
Cc: eric@cisu.net, kernel@kolivas.org, barryn@pobox.com,
swsnyder@insightbb.com, linux-kernel@vger.kernel.org
Subject: Re: HIGHMEM4G config for 1GB RAM on desktop?
Date: Wed, 04 Aug 2004 12:30:29 -0700 [thread overview]
Message-ID: <210450000.1091647829@flay> (raw)
In-Reply-To: <20040804120633.4dca57b3.akpm@osdl.org>
> 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.
>
> 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.
I had a patch for a config option, ported forward by someone at IBM (I forget
who, possibly Dave) from Andrea's original. I think we finally decided
(in consultation with Andrea) we could drop the complicated stuff he had
in the asm code, so it's pretty simple ... something like this:
diff -purN -X /home/mbligh/.diff.exclude 200-config_hz/arch/i386/Kconfig 210-config_page_offset/arch/i386/Kconfig
--- 200-config_hz/arch/i386/Kconfig 2004-03-14 09:48:36.000000000 -0800
+++ 210-config_page_offset/arch/i386/Kconfig 2004-03-14 09:49:04.000000000 -0800
@@ -763,6 +763,44 @@ config HIGHMEM64G
endchoice
+choice
+ help
+ On i386, a process can only virtually address 4GB of memory. This
+ lets you select how much of that virtual space you would like to
+ devoted to userspace, and how much to the kernel.
+
+ Some userspace programs would like to address as much as possible and
+ have few demands of the kernel other than it get out of the way. These
+ users may opt to use the 3.5GB option to give their userspace program
+ as much room as possible. Due to alignment issues imposed by PAE,
+ the "3.5GB" option is unavailable if "64GB" high memory support is
+ enabled.
+
+ Other users (especially those who use PAE) may be running out of
+ ZONE_NORMAL memory. Those users may benefit from increasing the
+ kernel's virtual address space size by taking it away from userspace,
+ which may not need all of its space. An indicator that this is
+ happening is when /proc/Meminfo's "LowFree:" is a small percentage of
+ "LowTotal:" while "HighFree:" is very large.
+
+ If unsure, say "3GB"
+ prompt "User address space size"
+ default 1GB
+
+config 05GB
+ bool "3.5 GB"
+ depends on !HIGHMEM64G
+
+config 1GB
+ bool "3 GB"
+
+config 2GB
+ bool "2 GB"
+
+config 3GB
+ bool "1 GB"
+endchoice
+
config HIGHMEM
bool
depends on HIGHMEM64G || HIGHMEM4G
diff -purN -X /home/mbligh/.diff.exclude 200-config_hz/arch/i386/Makefile 210-config_page_offset/arch/i386/Makefile
--- 200-config_hz/arch/i386/Makefile 2004-03-12 11:06:23.000000000 -0800
+++ 210-config_page_offset/arch/i386/Makefile 2004-03-14 09:49:04.000000000 -0800
@@ -114,6 +114,7 @@ drivers-$(CONFIG_PM) += arch/i386/powe
CFLAGS += $(mflags-y)
AFLAGS += $(mflags-y)
+AFLAGS_vmlinux.lds.o += -include $(TOPDIR)/include/asm-i386/page.h
boot := arch/i386/boot
diff -purN -X /home/mbligh/.diff.exclude 200-config_hz/include/asm-i386/page.h 210-config_page_offset/include/asm-i386/page.h
--- 200-config_hz/include/asm-i386/page.h 2004-03-12 11:07:27.000000000 -0800
+++ 210-config_page_offset/include/asm-i386/page.h 2004-03-14 09:49:04.000000000 -0800
@@ -97,9 +97,20 @@ typedef struct { unsigned long pgprot; }
#ifdef CONFIG_X86_4G_VM_LAYOUT
#define __PAGE_OFFSET (0x02000000)
#define TASK_SIZE (0xff000000)
-#else
+#elif defined(CONFIG_05GB)
+#define __PAGE_OFFSET (0xe0000000)
+#define TASK_SIZE (0xe0000000)
+#elif defined(CONFIG_1GB)
#define __PAGE_OFFSET (0xc0000000)
#define TASK_SIZE (0xc0000000)
+#elif defined(CONFIG_2GB)
+#define __PAGE_OFFSET (0x80000000)
+#define TASK_SIZE (0x80000000)
+#elif defined(CONFIG_3GB)
+#define __PAGE_OFFSET (0x40000000)
+#define TASK_SIZE (0x40000000)
+#else
+#error I have no idea what VM layout to use
#endif
/*
diff -purN -X /home/mbligh/.diff.exclude 200-config_hz/include/asm-i386/processor.h 210-config_page_offset/include/asm-i386/processor.h
--- 200-config_hz/include/asm-i386/processor.h 2004-03-12 11:07:47.000000000 -0800
+++ 210-config_page_offset/include/asm-i386/processor.h 2004-03-14 09:49:04.000000000 -0800
@@ -294,7 +294,11 @@ extern unsigned int mca_pentium_flag;
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
*/
+#ifdef CONFIG_05GB
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 16))
+#else
#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3))
+#endif
/*
* Size of io_bitmap, covering ports 0 to 0x3ff.
next prev parent reply other threads:[~2004-08-04 19:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-02 21:02 HIGHMEM4G config for 1GB RAM on desktop? Steve Snyder
2004-08-02 21:32 ` Bart Alewijnse
2004-08-02 22:05 ` Barry K. Nathan
2004-08-03 13:30 ` Jens Axboe
2004-08-03 14:13 ` Prakash K. Cheemplavam
2004-08-03 14:29 ` Con Kolivas
2004-08-04 6:06 ` Jens Axboe
2004-08-04 11:14 ` Eric Bambach
2004-08-04 13:07 ` Jens Axboe
2004-08-04 19:06 ` Andrew Morton
2004-08-04 19:21 ` Marc-Christian Petersen
2004-08-04 19:30 ` Martin J. Bligh [this message]
2004-08-04 19:51 ` Andrew Morton
2004-08-04 20:09 ` Martin J. Bligh
2004-08-04 20:09 ` Roland Dreier
2004-08-04 20:13 ` Martin J. Bligh
2004-08-12 0:53 ` Timothy Miller
2004-08-30 18:06 ` Timothy Miller
2004-08-30 17:49 ` Miquel van Smoorenburg
2004-08-31 22:46 ` Timothy Miller
2004-09-01 7:52 ` Miquel van Smoorenburg
2004-09-01 9:38 ` Matt Heler
[not found] ` <1094030083l.3189l.2l@traveler>
[not found] ` <1094030194l.3189l.3l@traveler>
[not found] ` <200409010233.31643.lkml@lpbproductions.com>
2004-09-01 9:58 ` 3ware queue depth [was: Re: HIGHMEM4G config for 1GB RAM on desktop?] Miquel van Smoorenburg
2004-09-01 10:09 ` Christoph Hellwig
2004-09-01 11:08 ` Miquel van Smoorenburg
2004-09-01 11:43 ` Christoph Hellwig
2004-09-01 19:43 ` Patrick Mansfield
2004-09-01 22:23 ` Miquel van Smoorenburg
2004-09-04 10:10 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2004-08-06 12:52 HIGHMEM4G config for 1GB RAM on desktop? linux
2004-08-07 0:20 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=210450000.1091647829@flay \
--to=mbligh@aracnet.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=barryn@pobox.com \
--cc=eric@cisu.net \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swsnyder@insightbb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox