Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932697Ab0HOQel (ORCPT ); Sun, 15 Aug 2010 12:34:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932128Ab0HOQej (ORCPT ); Sun, 15 Aug 2010 12:34:39 -0400 Message-ID: <4C6816BD.8060101@redhat.com> Date: Sun, 15 Aug 2010 19:33:01 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Steven Rostedt CC: Peter Zijlstra , Linus Torvalds , Mathieu Desnoyers , Frederic Weisbecker , Ingo Molnar , LKML , Andrew Morton , Thomas Gleixner , Christoph Hellwig , Li Zefan , Lai Jiangshan , Johannes Berg , Masami Hiramatsu , Arnaldo Carvalho de Melo , Tom Zanussi , KOSAKI Motohiro , Andi Kleen , "H. Peter Anvin" , Jeremy Fitzhardinge , "Frank Ch. Eigler" , Tejun Heo Subject: Re: [patch 1/2] x86_64 page fault NMI-safe References: <20100714184642.GA9728@elte.hu> <20100714193652.GA13630@nowhere> <20100714221418.GA14533@nowhere> <20100714223107.GA2350@Krystal> <20100714224853.GC14533@nowhere> <20100714231117.GA22341@Krystal> <20100714233843.GD14533@nowhere> <20100715162631.GB30989@Krystal> <1280855904.1923.675.camel@laptop> <1280903273.1923.682.camel@laptop> <1281537273.3058.14.camel@gandalf.stny.rr.com> In-Reply-To: <1281537273.3058.14.camel@gandalf.stny.rr.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1028 Lines: 25 On 08/11/2010 05:34 PM, Steven Rostedt wrote: > > So, I want to allocate a 10Meg buffer. I need to make sure the kernel > has 10megs of memory available. If the memory is quite fragmented, then > too bad, I lose out. With memory compaction, the cpu churns for a while, then you have your buffer. Of course there's still no guarantee, just a significantly higher probability of success. > Oh wait, I could also use vmalloc. But then again, now I'm blasting > valuable TLB entries for a tracing utility, thus making the tracer have > a even bigger impact on the entire system. Most trace entries will occupy much less than a page, and are accessed sequentially, so I don't think this will have a large impact. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/