From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 04 Feb 2003 07:55:32 -0800 From: "Martin J. Bligh" Subject: Re: hugepage patches Message-ID: <174080000.1044374131@[10.10.2.4]> In-Reply-To: References: <20030131151501.7273a9bf.akpm@digeo.com> <20030202025546.2a29db61.akpm@digeo.com> <20030202195908.GD29981@holomorphy.com> <20030202124943.30ea43b7.akpm@digeo.com> <20030203132929.40f0d9c0.akpm@digeo.com> <20030204055012.GD1599@holomorphy.com> <162820000.1044342992@[10.10.2.4]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mm@kvack.org Return-Path: To: "Eric W. Biederman" Cc: William Lee Irwin III , Andrew Morton , davem@redhat.com, rohit.seth@intel.com, davidm@napali.hpl.hp.com, anton@samba.org, linux-mm@kvack.org List-ID: >> > O.k. Then the code definitely needs to handle shared mappings.. >> >> Why? we just divided the pagetable size by a factor of 1000, so >> the problem is no longer really there ;-) > > William said one of the cases was to handle massively shared > mappings. You cannot create a massively shared mapping except by > sharing. > > Did I misunderstand what was meant by a massively shared mapping? > > I can't imagine it being useful to guys like oracle without MAP_SHARED > support.... Create a huge shmem segment. and don't share the pagetables. Without large pages, it's an enormous waste of space in mindless duplication. With large pages, it's a much smaller waste of space (no PTEs) in mindless duplication. Still not optimal, but makes the problem manageable. > Cool. I have no doubt the benefit is there. Measuring how large it > is will certainly be interesting. See the IBM research group's paper on large page support from last years OLS. Pretty impressive stuff. M. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/