On Mon, Oct 31, 2022 at 11:37:35AM +0800, Chen Wandun wrote:yes, experimental value, sorry for that.
I'm not sure what you mean by "experience value" but maybe you meantCan we set a experience value for pcp batch for each order during initUsing anything would than (X >> order) consumes storage. Even if storageAs is, the patch could result in a batch request of 0 andI foget this, the patch need some improve, thanks.
fall through to allocating from the zone list anyway defeating theSame as I understand???how about set high/batch for each order in pcplist???
purpose of the PCP allocator and probably regressing performance in some
csaes.
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.
stage?
experimental value?
Thank you for your suggestion, I will do some tests.
If so we can make accurately control for pcp size. Nowdays, the size of eachIt is something that could be experimented with but the main question is
order in pcp list is full of randomness. I dont konw which scheme is better
for performance.
-- 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.