Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752987AbbLICgg (ORCPT ); Tue, 8 Dec 2015 21:36:36 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:38356 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751381AbbLICge (ORCPT ); Tue, 8 Dec 2015 21:36:34 -0500 Date: Wed, 9 Dec 2015 03:36:32 +0100 From: Thomas Graf To: Herbert Xu Cc: David Miller , Phil Sutter , Eric Dumazet , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, fengguang.wu@intel.com, wfg@linux.intel.com, lkp@01.org Subject: Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation Message-ID: <20151209023632.GD19097@pox.localdomain> References: <20151207.142953.387889541116696974.davem@davemloft.net> <20151205070603.GB23255@gondor.apana.org.au> <20151209021826.GC19097@pox.localdomain> <20151209022454.GA24515@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151209022454.GA24515@gondor.apana.org.au> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1461 Lines: 33 On 12/09/15 at 10:24am, Herbert Xu wrote: > On Wed, Dec 09, 2015 at 03:18:26AM +0100, Thomas Graf wrote: > > > > Assuming that we only encounter this scenario with very large > > table sizes, it might be OK to assume that deferring the actual > > resize via the worker thread while continuing to insert above > > 100% utilization in atomic context is safe. > > As test_rhashtable has demonstrated already this approach doesn't > work. There is nothing in the kernel that will ensure that the > worker thread gets to run at all. If we define work assuming that an insertion in atomic context should never fail then yes. I'm not sure you can guarantee that with a segmented table either though. I agree though that the insertion behaviour is much better defined. My argument is that if we are in a situation in which a worker thread is never invoked and we've grown 2x from the original table size, do we still need entries to be inserted into the table or can we fail? Without knowing your exact implementation plans: introducing an additional reference indirection for every lookup will have a huge performance penalty as well. Is your plan to only introduce the master table after an allocation has failed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/