From: Prarit Bhargava <prarit@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org, Mike Galbraith <efault@gmx.de>,
Josh Triplett <josh@joshtriplett.org>,
Tim Abbott <tabbott@ksplice.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] module, fix percpu reserved memory exhaustion
Date: Mon, 14 Jan 2013 09:29:13 -0500 [thread overview]
Message-ID: <50F41639.2010305@redhat.com> (raw)
In-Reply-To: <87pq1byzum.fsf@rustcorp.com.au>
On 01/11/2013 08:06 PM, Rusty Russell wrote:
> Prarit Bhargava <prarit@redhat.com> writes:
>> On 01/10/2013 10:48 PM, Rusty Russell wrote:
>> The timing were similar. I didn't see any huge delays, etc. Can the
>> relocations really cause a long delay? I thought we were pretty much writing
>> values to memory...
>
> For x86 that's true, but look at what ppc64 has to do for example. I'm
> guessing you don't have a giant Nvidia proprietary driver module
> loading, either.
Ah -- I see. I hadn't thought much about the other arches and I see what ppc64
does ...
>
>> [I should point out that I'm booting a 32 physical/64 logical, with 64GB of memory]
>
> I figured it had to be something big ;)
:) Imagine what happens at 4096 cpus (SGI territory). I'm wondering about that
kvm commit. Maybe the systemd/udev rule needs to be rewritten to avoid a 'kvm
loading flood' during boot ... I'll talk with Kay Sievers about it to see if
there's a way around that.
>
> OTOH, Tested-by: means it actually fixed someone's problem.
Got it. For the record over-the-weekend testing didn't show any bizarre
results. The boot times were all around 20-23 seconds.
Tested-by: Prarit Bhargava <prarit@redhat.com>
P.
next prev parent reply other threads:[~2013-01-14 14:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 2:41 [PATCH] module, fix percpu reserved memory exhaustion Prarit Bhargava
2013-01-11 3:48 ` Rusty Russell
2013-01-11 14:16 ` Prarit Bhargava
2013-01-12 1:06 ` Rusty Russell
2013-01-14 14:29 ` Prarit Bhargava [this message]
2013-01-14 17:18 ` Tejun Heo
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=50F41639.2010305@redhat.com \
--to=prarit@redhat.com \
--cc=efault@gmx.de \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tabbott@ksplice.com \
--cc=tj@kernel.org \
/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.