From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E95A3C433FE for ; Tue, 15 Nov 2022 20:00:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 723866B0073; Tue, 15 Nov 2022 15:00:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ACAF8E0002; Tue, 15 Nov 2022 15:00:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54CE88E0001; Tue, 15 Nov 2022 15:00:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3ED6D6B0073 for ; Tue, 15 Nov 2022 15:00:23 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1BECE120B4A for ; Tue, 15 Nov 2022 20:00:23 +0000 (UTC) X-FDA: 80136743526.02.7571F9E Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf09.hostedemail.com (Postfix) with ESMTP id 9D16914000F for ; Tue, 15 Nov 2022 20:00:21 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id h14so14233228pjv.4 for ; Tue, 15 Nov 2022 12:00:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aUPcxz67kkweeebuGKEe2rhTN/W7CPDaGvYR4N7R0oY=; b=zyUbbNimKLtOxBvmGMfxabzC7apePpGXp5Vp0QpLu0PQ5qT+D0gtZLBNfWg/GCQwOT CEnd9cWHyiSHaywLJND5VQrrFVLrTw3RsKXGGMyHg3/FsrDaYuCx5z057tb5cWGUZB+S DpwxzOQdnijo3cz/U/TgaH4dElA8daf/drWLwXtvWXJNS7BOtn+9NPtlguSyAajX6U4M puNKMR6OZrF148vg+3qfw1cqzbHcdvFGuqDi9AHsQkE0CaRwDvTA0ywbP59pBnazmz6p R8R1vdgvMEVlbe3VKqe/hDO/z8J2Xa4847R1FLuyHXJ3fFv3qTkhQ96OB/LGljjQGMDv oPhg== X-Gm-Message-State: ANoB5pnLdbOX9T/2ee5um+aVZJBlaWNM/6NegKeGUrerdrjp04FFYgAy bbIpaFJwfeQKrhvW7Bxw20o= X-Google-Smtp-Source: AA0mqf6N8HbUSNV7IZxv0BLjsgEfM7drTGH32McnaDWbZ5cwVzuNAc5c2lnKP9QEdR2Xlz9PSZPhzA== X-Received: by 2002:a17:902:76c7:b0:185:46a5:1c73 with SMTP id j7-20020a17090276c700b0018546a51c73mr5545488plt.157.1668542420034; Tue, 15 Nov 2022 12:00:20 -0800 (PST) Received: from fedora ([2607:f598:b99a:be1:dfa7:eed0:45ca:de3c]) by smtp.gmail.com with ESMTPSA id k13-20020a170902ce0d00b0017f5ad327casm10269287plg.103.2022.11.15.12.00.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 12:00:19 -0800 (PST) Date: Tue, 15 Nov 2022 12:00:16 -0800 From: Dennis Zhou To: Baoquan He Cc: Vlastimil Babka , kernel test robot , oe-kbuild-all@lists.linux.dev, Linux Memory Management List , 42.hyeyoo@gmail.com Subject: Re: [linux-next:master 5002/7443] include/linux/compiler_types.h:357:45: error: call to '__compiletime_assert_474' declared with attribute error: BUILD_BUG_ON failed: PERCPU_DYNAMIC_EARLY_SIZE < NR_KMALLOC_TYPES * KMALLOC_SHIFT_HIGH * sizeof(struct kmem_cache_cpu) Message-ID: References: <202211120436.HzD1i2yQ-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668542421; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aUPcxz67kkweeebuGKEe2rhTN/W7CPDaGvYR4N7R0oY=; b=8HHeOwx+QLewANW0SD/YwF4ITEXJmjgZALDQDKFu+fEmBqmRbbk5K6d2cIPVBz866MRYF6 lCe8LoLXKQIQG/0j2LJlnxxZRwyQmFKw5yPPVmdnkDM4xeJvUdj2UVAHkbJjYYOF3Cnz8n 3SvL7zgai0/7Zj9hl59TRFJYlyCgWZY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668542421; a=rsa-sha256; cv=none; b=SYgn5akojn0jTs/Oty5sk0fkI2SzoOGuuY8ve+4Y4r80lOIssBtwDq7BAK99Z8/K9k7pMT Z9iVHrPvdMP0oA4RL71Yv0CIDneuPv3ytSD7ZoalXLxWkKCng9DCKDoGMg1jVDz3GtlUI2 lBkuiwrx9MmFbL7Rd0vV7n/m4uSjLcE= X-Rspam-User: X-Stat-Signature: 6eegcpwxq13ymympzhmphg6nfpfrq15d X-Rspamd-Queue-Id: 9D16914000F Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf09.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com X-Rspamd-Server: rspam07 X-HE-Tag: 1668542421-574085 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 15, 2022 at 05:08:52PM +0800, Baoquan He wrote: > Hi Dennis, > > On 11/14/22 at 08:13pm, Dennis Zhou wrote: > > Hi Vlastimil & Baoquan, > > > > On Mon, Nov 14, 2022 at 06:58:13PM +0100, Vlastimil Babka wrote: > > > On 11/14/22 08:44, Baoquan He wrote: > > > > Hi, > > > > > > > > I reproduced the build failure according to lkp report and made a patch > > > > as below to fix it. > > > > > > > > From dae7dd9705015ce36db757e88c78802584f949b1 Mon Sep 17 00:00:00 2001 > > > > From: Baoquan He > > > > Date: Sun, 13 Nov 2022 18:08:27 +0800 > > > > Subject: [PATCH] percpu: adjust the value of PERCPU_DYNAMIC_EARLY_SIZE > > > > Content-type: text/plain > > > > > > > > LKP reported a build failure as below on the patch "mm/slub, percpu: > > > > correct the calculation of early percpu allocation size" > > > > > > Since I have that patch in slab.git exposed to -next, should I take this fix > > > too, to make things simpler? Dennis? > > > > > > > I don't have any problems with you running a fix, but I'm not quite sure > > this is the right fix. Though this might cause a trivial merge conflict > > with: d667c94962c1 ("mm/percpu: remove unused PERCPU_DYNAMIC_EARLY_SLOTS") > > in my percpu#for-6.2 branch. > > > > If I'm understanding this correctly, slub requires additional percpu > > memory due to the use of 64k pages. By increasing > > PERCPU_DYNAMIC_EARLY_SIZE, we solve the problem for 64k page users, but > > require a few unnecessary pages that can bloat the size of subsequent > > percpu chunks. Though, I'm not sure if that's an issue today for > > embedded devices. > > Thanks for looking into this. > > I guess you are talking about PERCPU_DYNAMIC_EARLY_SIZE will impact the > first dynamic chunk size of page first chunk, because the embed first > chunk will take PERCPU_DYNAMIC_RESERVE. And the impact is done in below > max() invacation. > > static struct pcpu_alloc_info * __init __flatten pcpu_build_alloc_info( > size_t reserved_size, size_t dyn_size, > size_t atom_size, > pcpu_fc_cpu_distance_fn_t cpu_distance_fn) > { > ...... > /* calculate size_sum and ensure dyn_size is enough for early alloc */ > size_sum = PFN_ALIGN(static_size + reserved_size + > max_t(size_t, dyn_size, PERCPU_DYNAMIC_EARLY_SIZE)); > ...... > } > > > > > I think adding parity to PERCPU_DYNAMIC_EARLY_SIZE with > > PERCPU_DYNAMIC_RESERVE is defined by BITS_PER_LONG is a safer option > > here. A small TODO item would be to make PERCPU_DYNAMIC_RESERVE be a + > > value instead of a max() with PERCPU_DYNAMIC_EARLY_SIZE. > > Hmm, the below change may not take power arch into account. Please > check arch/powerpc/include/asm/page.h, seems the 32bit ppc could have > 256K pages too. Adding PERCPU_DYNAMIC_EARLY_SIZE to 20K may cost extra > memory during boot. But th left space of 1st dynamic chunk will join > the later percpu dynamic allocation, it's not wasted, right? > > Not sure if I got your point. > > Ah, I'm not familiar with all the PAGE_SIZE and word length combinations. The first chunk is smaller in the embedded case with the assumption that static percpu variables are highly accessed along with the limited initial allocations. While adding an additional 8KB is not the biggest deal to the first chunk, this can cause the unit_size for subsequent chunks to be larger. For example, x86 unit size jumps in powers of 2 due to alignment and packing against an allocation size of 2MB. So if we're at say 60KB for the first chunk, subsequent chunks could be 64KB. But adding 8KB, we'd go from 60KB -> 68KB and a chunk size of 64KB -> 128KB. If not `BITS_PER_LONG >32`, we could do `PAGE_SHIFT > 12`. Thanks, Dennis > > > > --- > > diff --git a/include/linux/percpu.h b/include/linux/percpu.h > > index f1ec5ad1351c..22ce3271eed2 100644 > > --- a/include/linux/percpu.h > > +++ b/include/linux/percpu.h > > @@ -42,7 +42,11 @@ > > * larger than PERCPU_DYNAMIC_EARLY_SIZE. > > */ > > #define PERCPU_DYNAMIC_EARLY_SLOTS 128 > > +#if BITS_PER_LONG > 32 > > +#define PERCPU_DYNAMIC_EARLY_SIZE (20 << 10) > > +#else > > #define PERCPU_DYNAMIC_EARLY_SIZE (12 << 10) > > +#endif > > > > /* > > * PERCPU_DYNAMIC_RESERVE indicates the amount of free area to piggy > > > >