All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Zhou <dennis@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Baoquan He <bhe@redhat.com>, kernel test robot <lkp@intel.com>,
	oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List <linux-mm@kvack.org>,
	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)
Date: Mon, 14 Nov 2022 20:13:25 -0800	[thread overview]
Message-ID: <Y3MR5ZA6DClG/2rC@fedora> (raw)
In-Reply-To: <dda9e5fc-258b-bf67-c90a-f7fb23ab68e3@suse.cz>

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 <bhe@redhat.com>
> > 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.

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.

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

  reply	other threads:[~2022-11-15  4:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 20:15 [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) kernel test robot
2022-11-12  0:45 ` Baoquan He
2022-11-14  7:44 ` Baoquan He
2022-11-14 17:58   ` Vlastimil Babka
2022-11-15  4:13     ` Dennis Zhou [this message]
2022-11-15  9:08       ` Baoquan He
2022-11-15 20:00         ` Dennis Zhou
2022-11-16 11:32           ` Baoquan He
2022-11-17 19:23             ` Dennis Zhou
2022-11-18  3:40               ` Baoquan He
2022-11-18  9:49               ` Vlastimil Babka
2022-11-18 19:08                 ` Dennis Zhou
2022-11-21  9:22                   ` Vlastimil Babka
2022-11-16 12:49           ` Hyeonggon Yoo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3MR5ZA6DClG/2rC@fedora \
    --to=dennis@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=bhe@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.