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
