[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070717193308.GD25301@v2.random>
Date: Tue, 17 Jul 2007 21:33:08 +0200
From: Andrea Arcangeli <andrea@...e.de>
To: William Lee Irwin III <wli@...omorphy.com>
Cc: Dave Hansen <haveblue@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
> You may rest assured that it's technically feasible. It's been done.
> The larger obstacles to all this are nontechnical.
Back then there was no variable order page size proposal, no slub,
generally nothing of that kind.
I think these days it worth to get it working again and solve the
technical obstacles once more time. Then we should plug into it a
pagecache logic to handle small files. That means if the soft page
size is 64k, we should kmalloc 32k of pagecache if the file is < 64k
but >= 32k, or kmalloc 16k if the file is < 32k but >= 16k, etc...
Down to 32bytes if we memcpy the 32bytes away to a 64k page, and we
disable the logic the moment somebody attempts to mmap the "kmalloced"
pagecache (which I think it's a lot simpler than trying to mmap a
kmalloced 4k naturally aligned object into userland). I wouldn't call
it tail packing, it's more a fine-granular pagecache with the already
available kmalloc granularities. That will maximize pagecache
utilization with read syscall for hg/git compared to current 2.6.22
plus memory will be allocated faster in 64k chunks etc... Ideally it
should be possible to disable the finer-granular-kmalloc-pagecache on
the big irons with lots of memory and only working with big files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists