Re: Re: [PATCH] kmalloc_index optimization(add kmalloc max size check)

[Michal Hocko]

On Fri 17-04-20 20:17:19, èåå wrote:
> 
> 
> From: Michal Hocko <mhocko@xxxxxxxxxx>
> Date: 2020-04-17 19:39:28
> To:  Bernard Zhao <bernard@xxxxxxxx>
> Cc:  Christoph Lameter <cl@xxxxxxxxx>,Pekka Enberg <penberg@xxxxxxxxxx>,David Rientjes <rientjes@xxxxxxxxxx>,Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>,Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,linux-mm@xxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx,kernel@xxxxxxxx
> Subject: Re: [PATCH] kmalloc_index optimization(add kmalloc max size check)>On Fri 17-04-20 00:09:35, Bernard Zhao wrote:
> >> kmalloc size should never exceed KMALLOC_MAX_SIZE.
> >> kmalloc_index realise if size is exceed KMALLOC_MAX_SIZE, e.g 64M,
> >> kmalloc_index just return index 26, but never check with OS`s max
> >> kmalloc config KMALLOC_MAX_SIZE. This index`s kmalloc caches maybe
> >> not create in function create_kmalloc_caches.
> >> We can throw an warninginfo in kmalloc at the beginning, instead of
> >> being guaranteed by the buddy alloc behind.
> >
> >I am sorry but I do not follow. What does this patch optimizes? AFAICS,
> >it adds a branch for everybody for something that is highly unlikely
> >usage. Btw. we already do handle those impossible cases. We could argue
> >that BUG() is a bit harsh reaction but a lack of reports suggests this
> >is not a real problem in fact.
> >
> >So what exactly do you want to achieve here?
> >
> 
> I'm not sure if my understanding has a gap. I think this should never happen. 

Yes. Have a look at the code and how all existing sizes map to an index
with a BUG() fallback so this is already handled. As I've said the
existing BUG() is far from optimal but a complete lack of bug reports
hitting this mark suggests this path is not really triggered.

And I do have objection to your patch. Because a) the description
doesn't state the problem which it is fixing and b) the patch adds a
test which everybody going this path has to evaluate and which should
never trigger. So despite your subject line, there is no actual
optimization but quite contrary.

-- 
Michal Hocko
SUSE Labs