linux-kernel - Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jul 2007 06:32:22 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Andrea Arcangeli <andrea@...e.de>
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.

On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
> 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...

Actually I'd worked on what was called MPSS (Multiple Page Size Support)
before I ever started on pgcl. Some large portion of the pgcl proposal
as I presented it internally was to reduce the order of large page
allocations and provide a promotion and demotion mechanism enabling
different processes to have different sized translations for the same
large page, and hence no out-of-context pagetable/TLB updates during
promotion and demotion, essentially by making the TLB translation to
page relation M:N. ISTR describing this in a KS presentation for which
IIRC you were present. But that's neither here nor there.


On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
> 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.

In any event, that is a sound strategy for mitigating internal
fragmentation of pagecache, though internal fragmentation of anonymous
memory has more severe consequences and is less easily mitigated.


-- wli
-
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/