Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 1 Nov 2022 10:40:40 +0000
From:   Mel Gorman <mgorman@techsingularity.net>
To:     Chen Wandun <chenwandun@huawei.com>
Cc:     akpm@linux-foundation.org, vbabka@suse.cz, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com
Subject: Re: [PATCH] mm: fix pcp count beyond pcp high in pcplist allocation
Message-ID: <20221101104040.o6gqtyyd5d4pkhle@techsingularity.net>
References: <20221024134146.3442393-1-chenwandun@huawei.com>
 <20221024145555.oaoisy6m723h4axc@techsingularity.net>
 <f189c530-1576-21fa-4c12-caa62739bbd0@huawei.com>
 <20221025131959.sd47fipimhehf76i@techsingularity.net>
 <316bc0a2-34d9-e485-11d2-f3dffd0fdea4@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <316bc0a2-34d9-e485-11d2-f3dffd0fdea4@huawei.com>
Precedence: bulk

On Mon, Oct 31, 2022 at 11:37:35AM +0800, Chen Wandun wrote:
> > > >    As is, the patch could result in a batch request of 0 and
> > >  ?I foget this, the patch need some improve, thanks.
> > > 
> > > > fall through to allocating from the zone list anyway defeating the
> > > > purpose of the PCP allocator and probably regressing performance in some
> > > > csaes.
> > > Same as I understand???how about set high/batch for each order in pcplist???
> > Using anything would than (X >> order) consumes storage. Even if storage
> > was to be used, selecting a value per-order would be impossible because
> > the correct value would depend on frequency of requests for each order.
> > That can only be determined at runtime and the cost of determining the
> > value would likely exceed the benefit.
>
> Can we set a experience value for pcp batch for each order during init
> stage?

I'm not sure what you mean by "experience value" but maybe you meant
experimental value?

> If so we can make accurately control for pcp size. Nowdays, the size of each
> order in pcp list is full of randomness. I dont konw which scheme is better
> for performance.
> 

It is something that could be experimented with but the main question is
-- what should those per-order values be? One option would be to enforce
pcp->high for all high-order values except THP if THP is enabled. That would
limit some of the issues with pcp->high being exceeded as even if two THPs
are refilled, one of them is allocated immediately. I wasn't convinced it was
necessary when implementing high-order PCP support but it could be evaluated.

-- 
Mel Gorman
SUSE Labs