Messages in this thread | | | Date | Fri, 17 Apr 2020 15:42:47 +0200 | From | Michal Hocko <> | Subject | Re: Re: [PATCH] kmalloc_index optimization(add kmalloc max size check) |
| |
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
| |