All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chegu Vinod <chegu_vinod@hp.com>
To: rusty@rustcorp.com.au, prarit@redhat.com,
	LKML <linux-kernel@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: KVM <kvm@vger.kernel.org>
Subject: kvm_intel: Could not allocate 42 bytes percpu data
Date: Mon, 24 Jun 2013 12:01:59 -0700	[thread overview]
Message-ID: <51C897A7.50302@hp.com> (raw)


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

... also call traces like the following...

[  101.852136]  ffffc901ad5aa090 ffff88084675dd08 ffffffff81633743 
ffff88084675ddc8
[  101.860889]  ffffffff81145053 ffffffff81f3fa78 ffff88084809dd40 
ffff8907d1cfd2e8
[  101.869466]  ffff8907d1cfd280 ffff88087fffdb08 ffff88084675c010 
ffff88084675dfd8
[  101.878190] Call Trace:
[  101.880953]  [<ffffffff81633743>] dump_stack+0x19/0x1e
[  101.886679]  [<ffffffff81145053>] pcpu_alloc+0x9a3/0xa40
[  101.892754]  [<ffffffff81145103>] __alloc_reserved_percpu+0x13/0x20
[  101.899733]  [<ffffffff810b2d7f>] load_module+0x35f/0x1a70
[  101.905835]  [<ffffffff8163ad6e>] ? do_page_fault+0xe/0x10
[  101.911953]  [<ffffffff810b467b>] SyS_init_module+0xfb/0x140
[  101.918287]  [<ffffffff8163f542>] system_call_fastpath+0x16/0x1b
[  101.924981] kvm_intel: Could not allocate 42 bytes percpu data


Wondering if anyone else has seen this with the recent [3.10] based 
kernels esp. on larger boxes?

There was a similar issue that was reported earlier (where modules were 
being loaded per cpu without checking if an instance was already 
loaded/being-loaded). That issue seems to have been addressed in the 
recent past (e.g. https://lkml.org/lkml/2013/1/24/659 along with a 
couple of follow on cleanups)   Is the above yet another variant of the 
original issue or perhaps some race condition that got exposed when 
there are lot more threads ?

Vinod

             reply	other threads:[~2013-06-24 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-24 19:01 Chegu Vinod [this message]
2013-06-24 22:52 ` kvm_intel: Could not allocate 42 bytes percpu data 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
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=51C897A7.50302@hp.com \
    --to=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 \
    --cc=rusty@rustcorp.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.