Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 17 Apr 2020 15:42:47 +0200
From:   Michal Hocko <mhocko@kernel.org>
To:     =?utf-8?B?6LW15Yab5aWO?= <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: Re: [PATCH] kmalloc_index optimization(add kmalloc max size
 check)
Message-ID: <20200417134247.GN26707@dhcp22.suse.cz>
References: <20200417113928.GL26707@dhcp22.suse.cz>
 <AOsA0QC2CNKuIHXhFI2eG4oJ.3.1587125839812.Hmail.bernard@vivo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AOsA0QC2CNKuIHXhFI2eG4oJ.3.1587125839812.Hmail.bernard@vivo.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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