All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>,
	cl@linux.com, penberg@kernel.org, rientjes@google.com,
	iamjoonsoo.kim@lge.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: kmalloc_index: remove case when size is more than 32MB
Date: Mon, 10 May 2021 22:58:57 +0900	[thread overview]
Message-ID: <20210510135857.GA3594@hyeyoo> (raw)
In-Reply-To: <c305ec02-a7d6-dd0c-bfee-e5b571d9ca9a@suse.cz>

On Mon, May 10, 2021 at 12:09:55PM +0200, Vlastimil Babka wrote:
> On 5/9/21 7:33 AM, Hyeonggon Yoo wrote:
> > On Sun, May 09, 2021 at 12:19:40AM +0100, Matthew Wilcox wrote:
> >> On Sun, May 09, 2021 at 07:13:28AM +0900, Hyeonggon Yoo wrote:
> >> > the return value of kmalloc_index is used as index of kmalloc_caches,
> >>
> >> it doesn't matter.  every few weeks somebody posts a patch to "optimise"
> >> kmalloc_index, failing to appreciate that it's only ever run at compile
> >> time because it's all under __builtin_constant_p().
> > 
> > Oh thanks, I didn't know about __builtin_constant_p.
> > 
> > But I was not optimizing kmalloc_index. isn't it confusing that
> > kmalloc_caches alllows maximum size of 32MB, and kmalloc_index allows
> > maximum size of 64MB?
> > 
> > and even if the code I removed is never reached because 64MB is always
> > bigger than KMALLOC_MAX_CACHE_SIZE, it will cause an error if reached.
> 
> KMALLOC_MAX_CACHE_SIZE depends on KMALLOC_SHIFT_HIGH
> size of kmalloc_caches array depends on KMALLOC_SHIFT_HIGH
> 
> So I don't an easy way how it could become reachable while causing the index to
> overflow - if someone increased KMALLOC_SHIFT_HIGH from 25 to 26, all should be
> fine, AFAICS.
> 
> The problem would be if someone increased it to 27, then we might suddenly get a
> BUG() in kmalloc_index(). We should probably replace that BUG() with
> BUILD_BUG_ON(1) to catch that at compile time. Hopefully no supported compiler
> will break because it's not able to do the proper compile-time evaluation - but
> if it does, at least we would know.
> 
> So I would accept the patch if it also changed BUG() to e.g. BUILD_BUG_ON_MSG(1,
> "unexpected size in kmalloc_index()");
> and expanded the function's comment that this is always compile-time evaluated
> and thus no attempts at "optimizing" the code should be made.
> 

Thank you so much reviewing and replying to my patch.
plecase check if I understood well.

Okay, I'll do that work. then the following patch will:
	- remove case when size is more than 32MB
	- change "BUG to BUILD_BUG_ON to let compiler know when the size is not supported"
	- add comment that there's no need to optimize it

is it what you mean. right?

and I have a question. in the lin 751 of mm/slab_common.c,
thre's struct kmalloc_info_struct kmalloc_info. and it initializes kmalloc info
up to 64MB, which is currently not supported. should I change it too? in a separate patch?


  reply	other threads:[~2021-05-10 13:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08 22:13 [PATCH] mm: kmalloc_index: remove case when size is more than 32MB Hyeonggon Yoo
2021-05-08 23:19 ` Matthew Wilcox
2021-05-09  5:33   ` Hyeonggon Yoo
2021-05-10 10:09     ` Vlastimil Babka
2021-05-10 13:58       ` Hyeonggon Yoo [this message]
2021-05-10 14:04         ` Vlastimil Babka
2021-05-10 15:02           ` [PATCH v2] mm: kmalloc_index: make compiler break when size is not supported Hyeonggon Yoo
2021-05-10 15:15             ` Christoph Lameter
2021-05-10 15:21               ` Vlastimil Babka
2021-05-11  3:09               ` Hyeonggon Yoo
2021-05-10 15:19             ` Vlastimil Babka
2021-05-10 15:38               ` Hyeonggon Yoo
2021-05-11  8:36                 ` Vlastimil Babka
2021-05-11  8:37                   ` Vlastimil Babka
2021-05-11  9:14                     ` Hyeonggon Yoo
2021-05-11  2:59               ` [PATCH v3] mm: change run-time assertion in kmalloc_index() to compile-time Hyeonggon Yoo
2021-05-10 15:44             ` [PATCH v2] mm: kmalloc_index: make compiler break when size is not supported Matthew Wilcox
2021-05-11  3:03               ` Hyeonggon Yoo
2021-05-11  8:33                 ` Vlastimil Babka

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=20210510135857.GA3594@hyeyoo \
    --to=42.hyeyoo@gmail.com \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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.