linux-kernel - Re: [RFC 7/8] Enhance ramfs to support higher order pages

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]

Message-ID: <20070420171118.GZ2986@holomorphy.com>
Date:	Fri, 20 Apr 2007 10:11:18 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Mel Gorman <mel@...net.ie>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <nickpiggin@...oo.com.au>, Andi Kleen <ak@...e.de>,
	Paul Jackson <pj@....com>, Dave Chinner <dgc@....com>
Subject: Re: [RFC 7/8] Enhance ramfs to support higher order pages

On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> Careful there. mmap() needs more than this.
>> (1) mapping->order is variable within an fs, so the architectural code
>> 	would need some vague awareness of the underlying page size
>> 	being variable unless the fs restricts it properly.

On Fri, Apr 20, 2007 at 09:30:30AM -0700, Christoph Lameter wrote:
> We can map arbitrary 4k chunks of larger pages.

The core VM can do that but the hugetlb architectural code can't fall
back to smaller page sizes. It also should not be put into a situation
where it needs to do so given the semantics it must honor.


On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> The hugetlbfs fs stub has by and large been a huge embarrassment to me,
>> so I'd welcome the opportunity to foist off the vfs lifting onto ramfs.
>> I'd be happier with real superpages, but it's not my kernel.

On Fri, Apr 20, 2007 at 09:30:30AM -0700, Christoph Lameter wrote:
> We are not doing superpages in any form. The filesystem determines it page 
> cache size thereby managing pages of arbitrary order. The usual VM 
> mmap will work using PAGE_SIZEd mappings as now (once that is working 
> right). There is no need to tie the page cache order to the page sizes 
> used by mmap or the sizes used by the fault handling of the VM.

Fine, s/real superpages/superpages/ -- I'm not picky enough.

Also, the final assertion is inaccurate. Fault handlers must instantiate
pages of order mapping->order when faulting in a page of a file with
a given pagecache size. The semantics of faulting and mmap()'ing are
slightly underspecified but no requirements for the size of the newly
established translations are included, so they can be PAGE_SIZE easily
enough.


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