From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: kvm_intel: Could not allocate 42 bytes percpu data Date: Tue, 02 Jul 2013 15:19:14 +0930 Message-ID: <8761wth5ph.fsf@rustcorp.com.au> References: <51C897A7.50302@hp.com> <87ehbisstv.fsf@rustcorp.com.au> <51D22931.1080008@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: prarit@redhat.com, LKML , Gleb Natapov , Paolo Bonzini , KVM To: Chegu Vinod Return-path: In-Reply-To: <51D22931.1080008@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Chegu Vinod writes: > On 6/30/2013 11:22 PM, Rusty Russell wrote: >> Chegu Vinod writes: >>> Hello, >>> >>> Lots (~700+) of the following messages are showing up in the dmesg of a >>> 3.10-rc1 based kernel (Host OS is running on a large socket count box >>> with HT-on). >>> >>> [ 82.270682] PERCPU: allocation failed, size=42 align=16, alloc from >>> reserved chunk failed >>> [ 82.272633] kvm_intel: Could not allocate 42 bytes percpu data >> Woah, weird.... >> >> Oh. Shit. Um, this is embarrassing. >> >> Thanks, >> Rusty. > > > Thanks for your response! > >> === >> module: do percpu allocation after uniqueness check. No, really! >> >> v3.8-rc1-5-g1fb9341 was supposed to stop parallel kvm loads exhausting >> percpu memory on large machines: >> >> Now we have a new state MODULE_STATE_UNFORMED, we can insert the >> module into the list (and thus guarantee its uniqueness) before we >> allocate the per-cpu region. >> >> In my defence, it didn't actually say the patch did this. Just that >> we "can". >> >> This patch actually *does* it. >> >> Signed-off-by: Rusty Russell >> Tested-by: Noone it seems. > > Your following "updated" fix seems to be working fine on the larger > socket count machine with HT-on. OK, did you definitely revert every other workaround? If so, please give me a Tested-by: line... Thanks, Rusty.