Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1930478ybl; Thu, 30 Jan 2020 08:28:59 -0800 (PST) X-Google-Smtp-Source: APXvYqwnWGyKZa2JRvrdnCPSuc6UZvmCoV/qzrP7sUvRZ8qynvhbPW5dNJ9ETA8NFoXf00xniSZn X-Received: by 2002:aca:ab53:: with SMTP id u80mr3346005oie.94.1580401739550; Thu, 30 Jan 2020 08:28:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580401739; cv=none; d=google.com; s=arc-20160816; b=JFrZXPQzR7VnWx2MH/VQcD1H2UP/69tGth3kMvvysRYmIlnxNr2dhbDRLtdlUDlpO0 Mht6vvLxM0vW3Se7+W0FCKpbR/NoClerrmfoQOstc/e9R0Jk9DSE8yDOESjP1Ot4446k /VpeVyxJI6EE9oWfqKomGgbY1oiFQsGkNqXJoAQt456XVWp2XE0AT4BFVSa938hWFIbY Bo7cllekO6lAXTePe8ZjDg+hLVm1+X0kl/p2Ncc430EpFwRh97h7HGE8VpYQ/3JQSqkg m9WO199Fm0qsu53fVgYbctczGOG4jcnGi+1sO9Z2KJ8dZxGmw2a7Pcl59Wn7u1pcYdQZ WxmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/fma7CgdCV/G2JwwzIFMHF8msbR1Qecf9iQd153zt+o=; b=V4FTB4m840BWGq3UjJxTUhdp1CMpkDZmaNr0eJIlweiIBzzPcbaMCyOuJ5PCbjZwpd +MDezGBRhF1x4opM7tV6ixfKfL341dq/n4VQ1Y4qXRn699BhxGM32AoloVl3Poj4RUec Qbr/fQDXM6rN8Ibm3IT5XVJsSqU3xuPXPUPXQSfdy11RHmlzKpyR4svXSc5Z1HGjx9Lc c9Lnd6hCy2923sqkw6cHmEyXofrAiMWjxbtkB8e8aDGDThYBKfm+XS3CfPjYF240yTNw lq6SEM2fiIA5T+/3GzuGACRZEjXGKsNW79cuGOAsSWSxz1mXPG2cd88D16caAw8iNUE2 qVsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 12si2840572oiz.131.2020.01.30.08.28.46; Thu, 30 Jan 2020 08:28:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727314AbgA3Q1o (ORCPT + 99 others); Thu, 30 Jan 2020 11:27:44 -0500 Received: from verein.lst.de ([213.95.11.211]:40913 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727263AbgA3Q1n (ORCPT ); Thu, 30 Jan 2020 11:27:43 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 442FB68C4E; Thu, 30 Jan 2020 17:27:41 +0100 (CET) Date: Thu, 30 Jan 2020 17:27:40 +0100 From: Christoph Hellwig To: Geert Uytterhoeven Cc: Eric Dumazet , Christoph Hellwig , linux-kernel , Eric Dumazet , Marek Szyprowski , Linux-Renesas Subject: Re: [PATCH] dma-debug: increase HASH_SIZE Message-ID: <20200130162740.GA6429@lst.de> References: <20191030184844.84219-1-edumazet@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 10, 2019 at 03:55:08PM +0100, Geert Uytterhoeven wrote: > On Wed, Oct 30, 2019 at 8:13 PM Eric Dumazet wrote: > > With modern NIC, it is not unusual having about ~256,000 active dma > > mappings. Hash size of 1024 buckets is too small. > > > > Forcing full cache line per bucket does not seem useful, > > especially now that we have a contention on free_entries_lock > > for allocations and freeing of entries. Better using space > > to fit more buckets. > > > > Signed-off-by: Eric Dumazet > > Cc: Christoph Hellwig > > Cc: Marek Szyprowski > > --- > > kernel/dma/debug.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c > > index 4ad74f5987ea9e95f9bb5e2d1592254e367d24fb..35e2a853bff9c482d789ab331d79aaee07753a97 100644 > > --- a/kernel/dma/debug.c > > +++ b/kernel/dma/debug.c > > @@ -27,7 +27,7 @@ > > > > #include > > > > -#define HASH_SIZE 1024ULL > > +#define HASH_SIZE 16384ULL > > #define HASH_FN_SHIFT 13 > > #define HASH_FN_MASK (HASH_SIZE - 1) > > > > @@ -87,7 +87,7 @@ typedef bool (*match_fn)(struct dma_debug_entry *, struct dma_debug_entry *); > > struct hash_bucket { > > struct list_head list; > > spinlock_t lock; > > -} ____cacheline_aligned_in_smp; > > +}; > > > > /* Hash list to save the allocated dma addresses */ > > static struct hash_bucket dma_entry_hash[HASH_SIZE]; > > JFTR, this increases dma_entry_hash size by 327680 bytes, and pushes > a few more boards beyond their bootloader-imposed kernel size limits. > > Disabling CONFIG_DMA_API_DEBUG fixes that. > Of course the real fix is to fix the bootloaders... Can someone just send a patch to switch this to a dynamic allocation?