Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5989470imm; Mon, 23 Jul 2018 09:26:39 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcCJdj4FoW/fghhET2obPPuxeEAiVab7HfHNoQlWi/aF9iyRRRKAc36hXr4BughGWajh+0a X-Received: by 2002:a62:8559:: with SMTP id u86-v6mr14013420pfd.32.1532363199055; Mon, 23 Jul 2018 09:26:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532363199; cv=none; d=google.com; s=arc-20160816; b=enrNbx/yN2tzPrDq0YXwsBv8Eq+Tl+xKZCNk964DAPlS9fTaduPljEcirCP7kDYDbi m6D5ZCnxo6lquCIVQlthoQSvemlCMObxSRu5EaHZmYrq6BsWnrz0+s2a3ZWyTZlE1jy+ P+usZBX3nPbIJla4I5czn2O9uaMQDl9Rsqr2TZlRjYcOeRBbZWLM7Po3skAVeBMenpag i3NT23kWUqgEsrEBuNH3tWf0q1o2bVcVtG96T7JK1ooKdN3n7qt6L+L7f8iIOzvzCDqU hV3iS/lIrNSEXSJVg+YxGdG5qFNcdTLgV4QBCDmf9iwkbNmsJPb2rRX1QcH254n2s3mb I2pQ== 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:dkim-signature:arc-authentication-results; bh=xU3ke70QOQa+qEsX4FUu9AuN3la6fGruwp6cDYTLZ28=; b=Jnzz+EMoiqdEzgLCUQKwqrJrJOHiw3ZI2x9ub2wn1qKUxxVcnQPwjoKA9EGITByc0K eUV495u55YFXKpKFD+cBiNlofyg/V/ssFpsB8lItrZu2D+zQdeocUANUogFjsJbDKvj2 NMDpRCegq7ccx4awxSTReSDIACsxZcgfYdnwMiWKirkqZlA+We2H1FA7ayGnUmkmwPfg R8EyAlaUZ+N8zVzLd+UUUpfBzdOK7aiBZk1tuIrr+qibJnPWpmeeIDfsB5zgzw3PUuMh amjudeUX30dxDTLgv4eK79G91IsClQi6doMllwCfDnwAQ1i4dimww8meY+7hHmoske9E u64Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="Kq/KjY7r"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d39-v6si8580545pla.41.2018.07.23.09.26.24; Mon, 23 Jul 2018 09:26:39 -0700 (PDT) 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; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b="Kq/KjY7r"; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388744AbeGWR0p (ORCPT + 99 others); Mon, 23 Jul 2018 13:26:45 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:39007 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388135AbeGWR0p (ORCPT ); Mon, 23 Jul 2018 13:26:45 -0400 Received: by mail-yw0-f195.google.com with SMTP id r184-v6so434920ywg.6 for ; Mon, 23 Jul 2018 09:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xU3ke70QOQa+qEsX4FUu9AuN3la6fGruwp6cDYTLZ28=; b=Kq/KjY7rlehegj+32r7JJ1BzZKdEnhujKlv3ke0lNs5DtwF7MRv9XqSx1DvRSo3LA9 7L8Nvv/4Qq56tkuUapsGMujOEYv7lR+eg3Oxl3QUBxH6DLpkoj0TyJlxF493UpK7C5YM FYse6ZWJm0NZMUJAadYQs31UUQNMAH3V4i8OdoE1Lz84IwxHc5gaWY2QQLye9BVnS6GB 9FdnEyyab7+fEf+ja0K3oD3xkXnx9RGXYwr/M+z4LCn3V7Y87Y4vHfH30HN7W84EapH5 FX1I0W+IqkLPXeKjnmDunl4Lh47IpC+0mvFe/FqA+n1e6bGVsuyfVsaBs6W3byBIzHDY nQhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xU3ke70QOQa+qEsX4FUu9AuN3la6fGruwp6cDYTLZ28=; b=VfUTyN/kLcj/6rb8FGyvjBuHbT/QJMgu9rW47P4GVZv2c50JMKJlvhoCxkIOUh6n6q 8C00K0ahadH7FNUMzrqgwXsj4wiLZGC0mpFOj5d0QbSmSO6kSBj8fABP2OuQN1c1ZvwC Uvn1exOjDHs0xwKege0wGpzZcVl9OHBZgy6QKAXoZv+ILvnbNOTIqZbCFdYJPJYuqUzR vvpGsMaaLwdLB0UhA9Q3SRxcBo8GMnL/Hxca7QgntwGr2yNj304lQ3kE2uRs0uY3fSpz mReO/w3yLj8tKFeQx/gZOWCPYD1ReiREqIt/wPdQu6qi0eoU7/YE9aWSwHN/AxoBQVxk pE+g== X-Gm-Message-State: AOUpUlHd0/XDWSkzceXaki2DxFZUGteUYZnUEXn5WbeR9KGC+OnvN5Pn 3MTFvP5gOSc+GKOrVlwfuVVhhg== X-Received: by 2002:a0d:d516:: with SMTP id x22-v6mr7366067ywd.230.1532363086003; Mon, 23 Jul 2018 09:24:46 -0700 (PDT) Received: from localhost ([2620:10d:c091:180::1:3a18]) by smtp.gmail.com with ESMTPSA id e72-v6sm7323822ywa.61.2018.07.23.09.24.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Jul 2018 09:24:44 -0700 (PDT) Date: Mon, 23 Jul 2018 12:27:35 -0400 From: Johannes Weiner To: Arnd Bergmann Cc: Peter Zijlstra , Suren Baghdasaryan , Mike Galbraith , Will Deacon , Linux Kernel Mailing List , kernel-team@fb.com, Linux-MM , Vinayak Menon , Ingo Molnar , Shakeel Butt , Catalin Marinas , Tejun Heo , cgroups@vger.kernel.org, Andrew Morton , Linus Torvalds , Christopher Lameter , Linux ARM Subject: Re: [PATCH 02/10] mm: workingset: tell cache transitions from workingset thrashing Message-ID: <20180723162735.GA5980@cmpxchg.org> References: <20180712172942.10094-1-hannes@cmpxchg.org> <20180712172942.10094-3-hannes@cmpxchg.org> <20180723152323.GA3699@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 23, 2018 at 05:35:35PM +0200, Arnd Bergmann wrote: > On Mon, Jul 23, 2018 at 5:23 PM, Johannes Weiner wrote: > > From 1d24635a6c7cd395bad5c29a3b9e5d2e98d9ab84 Mon Sep 17 00:00:00 2001 > > From: Johannes Weiner > > Date: Mon, 23 Jul 2018 10:18:23 -0400 > > Subject: [PATCH] arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap > > setups > > > > Arnd reports the following arm64 randconfig build error with the PSI > > patches that add another page flag: > > > > You could add further text here that I had just added to my > patch description (not sent): > > Further experiments show that the build error already existed before, > but was only triggered with larger values of CONFIG_NR_CPU and/or > CONFIG_NODES_SHIFT that might be used in actual configurations but > not in randconfig builds. > > With longer CPU and node masks, I could recreate the problem with > kernels as old as linux-4.7 when arm64 NUMA support got added. > > Cc: stable@vger.kernel.org > Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") > Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below > the linear region") Sure thing. > > arch/arm64/mm/init.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index 1b18b4722420..72c9b6778b0a 100644 > > --- a/arch/arm64/mm/init.c > > +++ b/arch/arm64/mm/init.c > > @@ -611,11 +611,13 @@ void __init mem_init(void) > > BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64); > > #endif > > > > +#ifndef CONFIG_SPARSEMEM_VMEMMAP > > /* > > I tested it on two broken configurations, and found that you have > a typo here, it should be 'ifdef', not 'ifndef'. With that change, it > seems to build fine. > > Tested-by: Arnd Bergmann Thanks for testing it, I don't have a cross-compile toolchain set up. --- From 34c4c4549f09f971d2d391a8d652d56cb9b05475 Mon Sep 17 00:00:00 2001 From: Johannes Weiner Date: Mon, 23 Jul 2018 10:18:23 -0400 Subject: [PATCH] arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap setups Arnd reports the following arm64 randconfig build error with the PSI patches that add another page flag: /git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init': /git/arm-soc/include/linux/compiler.h:357:38: error: call to '__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT) The additional page flag causes other information stored in page->flags to get bumped into their own struct page member: #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= BITS_PER_LONG - NR_PAGEFLAGS #define LAST_CPUPID_WIDTH LAST_CPUPID_SHIFT #else #define LAST_CPUPID_WIDTH 0 #endif #if defined(CONFIG_NUMA_BALANCING) && LAST_CPUPID_WIDTH == 0 #define LAST_CPUPID_NOT_IN_PAGE_FLAGS #endif which in turn causes the struct page size to exceed the size set in STRUCT_PAGE_MAX_SHIFT. This value is an an estimate used to size the VMEMMAP page array according to address space and struct page size. However, the check is performed - and triggers here - on a !VMEMMAP config, which consumes an additional 22 page bits for the sparse section id. When VMEMMAP is enabled, those bits are returned, cpupid doesn't need its own member, and the page passes the VMEMMAP check. Restrict that check to the situation it was meant to check: that we are sizing the VMEMMAP page array correctly. Says Arnd: Further experiments show that the build error already existed before, but was only triggered with larger values of CONFIG_NR_CPU and/or CONFIG_NODES_SHIFT that might be used in actual configurations but not in randconfig builds. With longer CPU and node masks, I could recreate the problem with kernels as old as linux-4.7 when arm64 NUMA support got added. Reported-by: Arnd Bergmann Tested-by: Arnd Bergmann Cc: stable@vger.kernel.org Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below the linear region") Signed-off-by: Johannes Weiner --- arch/arm64/mm/init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 1b18b4722420..86d9f9d303b0 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -611,11 +611,13 @@ void __init mem_init(void) BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64); #endif +#ifdef CONFIG_SPARSEMEM_VMEMMAP /* * Make sure we chose the upper bound of sizeof(struct page) - * correctly. + * correctly when sizing the VMEMMAP array. */ BUILD_BUG_ON(sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)); +#endif if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) { extern int sysctl_overcommit_memory; -- 2.18.0