From: Rusty Russell <rusty@rustcorp.com.au>
To: Chegu Vinod <chegu_vinod@hp.com>
Cc: prarit@redhat.com, LKML <linux-kernel@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, KVM <kvm@vger.kernel.org>
Subject: Re: kvm_intel: Could not allocate 42 bytes percpu data
Date: Tue, 02 Jul 2013 15:19:14 +0930 [thread overview]
Message-ID: <8761wth5ph.fsf@rustcorp.com.au> (raw)
In-Reply-To: <51D22931.1080008@hp.com>
Chegu Vinod <chegu_vinod@hp.com> writes:
> On 6/30/2013 11:22 PM, Rusty Russell wrote:
>> Chegu Vinod <chegu_vinod@hp.com> 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 <rusty@rustcorp.com.au>
>> 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.
next prev parent reply other threads:[~2013-07-02 5:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 19:01 kvm_intel: Could not allocate 42 bytes percpu data Chegu Vinod
2013-06-24 22:52 ` Prarit Bhargava
2013-06-27 0:53 ` Marcelo Tosatti
2013-07-01 6:22 ` Rusty Russell
2013-07-02 1:13 ` Chegu Vinod
2013-07-02 5:49 ` Rusty Russell [this message]
2013-07-02 16:34 ` Chegu Vinod
2013-07-03 0:37 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761wth5ph.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=chegu_vinod@hp.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=prarit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).