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: Wed, 03 Jul 2013 10:07:55 +0930 Message-ID: <87hagcfpgc.fsf@rustcorp.com.au> References: <51C897A7.50302@hp.com> <87ehbisstv.fsf@rustcorp.com.au> <51D22931.1080008@hp.com> <8761wth5ph.fsf@rustcorp.com.au> <51D3012A.4030306@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: prarit@redhat.com, LKML , Gleb Natapov , Paolo Bonzini , KVM , "Hull\, Jim" To: Chegu Vinod Return-path: In-Reply-To: <51D3012A.4030306@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Chegu Vinod writes: > On 7/1/2013 10:49 PM, Rusty Russell wrote: >> Chegu Vinod writes: >>> On 6/30/2013 11:22 PM, Rusty Russell wrote: >>>> 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? > > Yes no other workarounds were there when your change was tested. > >> >> If so, please give me a Tested-by: line... > > FYI.... The actual verification of your change was done by my esteemed > colleague :Jim Hull (cc'd) who had access to this larger socket count box. > > > > Tested-by: Jim Hull Thanks, I've put this in my -next tree, and CC'd stable. Cheers, Rusty.