Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753340AbbLICZO (ORCPT ); Tue, 8 Dec 2015 21:25:14 -0500 Received: from helcar.hengli.com.au ([209.40.204.226]:59330 "EHLO helcar.hengli.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752862AbbLICZL (ORCPT ); Tue, 8 Dec 2015 21:25:11 -0500 Date: Wed, 9 Dec 2015 10:24:54 +0800 From: Herbert Xu To: Thomas Graf 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: <20151209022454.GA24515@gondor.apana.org.au> References: <20151207.142953.387889541116696974.davem@davemloft.net> <20151205070603.GB23255@gondor.apana.org.au> <20151209021826.GC19097@pox.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151209021826.GC19097@pox.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 879 Lines: 21 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. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/