Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753025AbbLICSa (ORCPT ); Tue, 8 Dec 2015 21:18:30 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38777 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbbLICS3 (ORCPT ); Tue, 8 Dec 2015 21:18:29 -0500 Date: Wed, 9 Dec 2015 03:18:26 +0100 From: Thomas Graf To: Herbert Xu , David Miller Cc: 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: <20151209021826.GC19097@pox.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151207.142953.387889541116696974.davem@davemloft.net> <20151205070603.GB23255@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: 849 Lines: 19 On 12/05/15 at 03:06pm, Herbert Xu wrote: > Unless we can make __vmalloc work with BH disabled, I guess we'll > have to go back to multi-level lookups unless someone has a better > suggestion. 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. On 12/07/15 at 02:29pm, David Miller wrote: > You can't issue the cross-cpu TLB flushes from atomic contexts. > It's the kernel page table updates that create the restriction. -- 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/