lkml.org 
[lkml]   [2013]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] module, fix percpu reserved memory exhaustion
Date
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.

It just makes me nervous; this kind of boot slowdown typically won't get
diagnosed for several releases, if ever. Now I've done the work, I'm
going to apply my patch (with an additional fix: I forgot to change
kgdb, which traverses the module list too).

> [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 ;)

>> We currently have PERCPU_MODULE_RESERVE set at 8k: in my 32-bit
>> allmodconfig build, there are only three modules with per-cpu data,
>> totalling 328 bytes. So it's not reasonable to increase that number to
>> paper over this.
>
> I've been thinking about that. The problem is that at the same time the kvm
> problem occurs I'm attempting to load a debug module that I've written to debug
> some cpu timer issues that allocates a large amount of percpu data (~.5K/cpu).
> While extending PERCPU_MODULE_RESERVE to 10k might work now, it might not work
> tomorrow if I have the need to increase the size of my log buffer.

Well, it looks like PERCPU_MODULE_RESERVE is actually very generous; it
could easily be halved. I guess this is because dynamic per-cpu data is
now such a nice alternative (thanks to Tejun).

> <snip patch>
>
> Tested-by: Prarit Bhargava <prarit@redhat.com>
>
> Rusty, you can change that to an Acked-by if you prefer that. I know some
> engineers prefer one over the other. I'll also continue doing some reboot
> testing and will email back in a few days to let you know what the timing looks
> like.

There seem to be two kinds of Acked-by:

1) Acked-by: <maintainer>. ie. "this should go through my tree, but
it's going via someone else". I like this: shows the normal
maintainer is aware of the change.

2) Acked-by: <random>. ie. "I like the concept of the patch though I
haven't actually read it or tested it". Completely useless.

OTOH, Tested-by: means it actually fixed someone's problem.

Thanks!
Rusty.


\
 
 \ /
  Last update: 2013-01-12 03:01    [W:0.053 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site