From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Graf <tgraf@suug.ch>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
davem@davemloft.net, paulmck@linux.vnet.ibm.com,
john.r.fastabend@intel.com, kaber@trash.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] rhashtable: Remove gfp_flags from insert and remove functions
Date: Tue, 23 Sep 2014 21:11:31 -0700 [thread overview]
Message-ID: <87sijhwtcc.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140915124937.GB21541@casper.infradead.org> (Thomas Graf's message of "Mon, 15 Sep 2014 13:49:37 +0100")
Thomas Graf <tgraf@suug.ch> writes:
> On 09/15/14 at 05:35am, Eric Dumazet wrote:
>> On Mon, 2014-09-15 at 14:18 +0200, Thomas Graf wrote:
>> > As the expansion/shrinking is moved to a worker thread, no allocations
>> > will be performed anymore.
>> >
>>
>> You meant : no GFP_ATOMIC allocations ?
>>
>> I would rephrase using something like :
>>
>> Because hash resizes are potentially time consuming, they'll be
>> performed in process context where GFP_KERNEL allocations are preferred.
>
> I meant to say no allocations in insert/remove anymore but your wording
> is even clearer. I'll update it.
>
>> > - tbl = kzalloc(size, flags);
>> > + tbl = kzalloc(size, GFP_KERNEL);
>>
>> Add __GFP_NOWARN, as you fallback to vzalloc ?
>
> Good point.
It needs to be both __GFP_NOWARN and __GFP_NORETRY.
Otherwise the system will kick in the OOM killer before it falls back to
vzalloc. Which I can't imagine anyone wanting.
Look at the history of alloc_fdmem in fs/file.c for the real world
reasoning.
Eric
next prev parent reply other threads:[~2014-09-24 4:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 12:17 [PATCH 0/5 RFC net-next] rhashtable: Parallel atomic insert/deletion & deferred expansion Thomas Graf
2014-09-15 12:18 ` [PATCH 1/5] rhashtable: Remove gfp_flags from insert and remove functions Thomas Graf
2014-09-15 12:35 ` Eric Dumazet
2014-09-15 12:49 ` Thomas Graf
2014-09-15 14:49 ` Eric Dumazet
2014-09-15 14:56 ` Thomas Graf
2014-09-24 4:11 ` Eric W. Biederman [this message]
2014-09-15 12:18 ` [PATCH 2/5] rhashtable: Check for count misatch in selftest Thomas Graf
2014-09-15 12:18 ` [PATCH 3/5] rhashtable: Convert to nulls list Thomas Graf
2014-09-15 12:18 ` [PATCH 4/5] spinlock: Add spin_lock_bh_nested() Thomas Graf
2014-09-15 12:18 ` [PATCH 5/5] rhashtable: Per bucket locks & expansion/shrinking in work queue Thomas Graf
2014-09-15 15:23 ` Eric Dumazet
2014-09-16 13:22 ` Thomas Graf
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=87sijhwtcc.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=john.r.fastabend@intel.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tgraf@suug.ch \
/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
Powered by JetHome