From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 18 Sep 2008 16:26:44 +0900 From: KAMEZAWA Hiroyuki Subject: Re: Populating multiple ptes at fault time Message-Id: <20080918162644.1d4beab7.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <28c262360809171650g1395bbe2ya4e560851d37760d@mail.gmail.com> References: <48D142B2.3040607@goop.org> <28c262360809171650g1395bbe2ya4e560851d37760d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: MinChan Kim Cc: Jeremy Fitzhardinge , Rik van Riel , Andrew Morton , Nick Piggin , Hugh Dickens , Linux Memory Management List , Linux Kernel Mailing List , Avi Kivity List-ID: On Thu, 18 Sep 2008 08:50:05 +0900 "MinChan Kim" wrote: > Hi, all > > I have been thinking about this idea in native. > I didn't consider it in minor page fault. > As you know, it costs more cheap than major fault. > However, the page fault is one of big bottleneck on demand-paging system. > I think major fault might be a rather big overhead in many core system. > > What do you think about this idea in native ? > Do you really think that this idea don't help much in native ? > Hmm, is enlarging page-size-for-anonymous-page more difficult ? (maybe, yes.) > If I implement it in native, What kinds of benchmark do I need? > Could you recommend any benchmark ? > Testing some kind of scripts (shell/perl etc..) is candidates. I use unixbench's exec/shell test to see charge/uncharge overhead of memory resource controller, which happens at major page fault. Thanks, -Kame -- 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/ . Don't email: email@kvack.org