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

[Michal Hocko <mhocko@kernel.org>]

On Fri 17-04-20 20:17:19, 赵军奎 wrote:
> 
> 
> From: Michal Hocko <mhocko@kernel.org>
> Date: 2020-04-17 19:39:28
> To:  Bernard Zhao <bernard@vivo.com>
> Cc:  Christoph Lameter <cl@linux.com>,Pekka Enberg <penberg@kernel.org>,David Rientjes <rientjes@google.com>,Joonsoo Kim <iamjoonsoo.kim@lge.com>,Andrew Morton <akpm@linux-foundation.org>,linux-mm@kvack.org,linux-kernel@vger.kernel.org,kernel@vivo.com
> 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