From: Eric Dumazet <eric.dumazet@gmail.com>
To: Phil Sutter <phil@nwl.cc>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, tgraf@suug.ch,
fengguang.wu@intel.com, wfg@linux.intel.com, lkp@01.org
Subject: Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation
Date: Fri, 04 Dec 2015 09:45:20 -0800 [thread overview]
Message-ID: <1449251120.25029.31.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <20151204170101.GB29598@orbit.nwl.cc>
On Fri, 2015-12-04 at 18:01 +0100, Phil Sutter wrote:
> On Fri, Dec 04, 2015 at 10:39:56PM +0800, Herbert Xu wrote:
> > On Thu, Dec 03, 2015 at 08:08:39AM -0800, Eric Dumazet wrote:
> > >
> > > Anyway, __vmalloc() can be used with GFP_ATOMIC, have you tried this ?
> >
> > OK I've tried it and I no longer get any ENOMEM errors!
>
> I can't confirm this, sadly. Using 50 threads, results seem to be stable
> and good. But increasing the number of threads I can provoke ENOMEM
> condition again. See attached log which shows a failing test run with
> 100 threads.
>
> I tried to extract logs of a test run with as few as possible failing
> threads, but wasn't successful. It seems like the error amplifies
> itself: While having stable success with less than 70 threads, going
> beyond a margin I could not identify exactly, much more threads failed
> than expected. For instance, the attached log shows 70 out of 100
> threads failing, while for me every single test with 50 threads was
> successful.
>
> HTH, Phil
But this patch is about GFP_ATOMIC allocations, I doubt your test is
using GFP_ATOMIC.
Threads (process context) should use GFP_KERNEL allocations.
BTW, if 100 threads are simultaneously trying to vmalloc(32 MB), this
might not be very wise :(
Only one should really do this, while others are waiting.
If we really want parallelism (multiple cpus coordinating their effort),
it should be done very differently.
next prev parent reply other threads:[~2015-12-04 17:45 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 17:17 [PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test Phil Sutter
2015-11-20 17:17 ` [PATCH v2 1/4] rhashtable-test: add cond_resched() to thread test Phil Sutter
2015-11-20 17:17 ` [PATCH v2 2/4] rhashtable-test: retry insert operations Phil Sutter
2015-11-20 17:17 ` [PATCH v2 3/4] rhashtable-test: calculate max_entries value by default Phil Sutter
2015-11-20 17:17 ` [PATCH v2 4/4] rhashtable-test: allow to retry even if -ENOMEM was returned Phil Sutter
2015-11-20 17:28 ` Phil Sutter
2015-11-23 17:38 ` [PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test David Miller
2015-11-30 9:37 ` Herbert Xu
2015-11-30 10:14 ` Phil Sutter
2015-11-30 10:18 ` Herbert Xu
2015-12-03 12:41 ` rhashtable: Prevent spurious EBUSY errors on insertion Herbert Xu
2015-12-03 15:38 ` Phil Sutter
2015-12-04 19:38 ` David Miller
2015-12-17 8:46 ` Xin Long
2015-12-17 8:48 ` Herbert Xu
2015-12-17 9:00 ` Xin Long
2015-12-17 16:07 ` Xin Long
2015-12-18 2:26 ` Herbert Xu
2015-12-18 8:18 ` Xin Long
2015-12-17 17:00 ` David Miller
2015-12-03 12:51 ` rhashtable: ENOMEM errors when hit with a flood of insertions Herbert Xu
2015-12-03 15:08 ` David Laight
2015-12-03 16:08 ` Eric Dumazet
2015-12-04 0:07 ` Herbert Xu
2015-12-04 14:39 ` rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Herbert Xu
2015-12-04 17:01 ` Phil Sutter
2015-12-04 17:45 ` Eric Dumazet [this message]
2015-12-04 18:15 ` Phil Sutter
2015-12-05 7:06 ` Herbert Xu
2015-12-07 15:35 ` Thomas Graf
2015-12-07 19:29 ` David Miller
2015-12-09 2:18 ` Thomas Graf
2015-12-09 2:24 ` Herbert Xu
2015-12-09 2:36 ` Thomas Graf
2015-12-09 2:38 ` Herbert Xu
2015-12-09 2:42 ` Thomas Graf
2015-12-04 21:53 ` David Miller
2015-12-05 7:03 ` Herbert Xu
2015-12-06 3:48 ` David Miller
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=1449251120.25029.31.camel@edumazet-glaptop2.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=fengguang.wu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=netdev@vger.kernel.org \
--cc=phil@nwl.cc \
--cc=tgraf@suug.ch \
--cc=wfg@linux.intel.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).