[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZB4x6IY/8P1Xam7d@bombadil.infradead.org>
Date: Fri, 24 Mar 2023 16:27:36 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Hildenbrand <david@...hat.com>,
Kees Cook <keescook@...omium.org>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
pmladek@...e.com, petr.pavlu@...e.com, prarit@...hat.com,
christophe.leroy@...roup.eu, song@...nel.org, dave@...olabs.net,
fan.ni@...sung.com, vincent.fu@...sung.com,
a.manzanares@...sung.com, colin.i.king@...il.com
Subject: Re: [RFC 00/12] module: avoid userspace pressure on unwanted
allocations
On Fri, Mar 24, 2023 at 02:14:11PM -0700, Luis Chamberlain wrote:
> On Fri, Mar 24, 2023 at 01:28:51PM -0700, Linus Torvalds wrote:
> > +static CONCURRENCY_LIMITER(module_loading_concurrency, 50);
> I'll give it a good wack thanks.
Using a value of 20 above matches what I to get up to 100 stress-ng
module ops without any OOM (which seems to mimick a 400 CPU environment):
echo 0 > /proc/sys/vm/oom_dump_tasks
./stress-ng --module 100 --module-name xfs
I'll go with that and evaluate max memory usage as well, but this is
still inviting us to consider other users interfacing areas with an
implicated vmalloc and the scale of this as we grow number of CPU
counts.
A magic values of 20 is completely empirical.
Luis
Powered by blists - more mailing lists