On 8/5/22 06:38, Vlastimil Babka wrote: >> I'm sure we could optimize for the !unaccepted memory via static keys >> also in this version with some checks at the right places if we find >> this to hurt performance? > It would be great if we would at least somehow hit the necessary code only > when dealing with a >=pageblock size block. The bitmap approach and > accepting everything smaller uprofront actually seems rather compatible. Yet > in the current patch we e.g. check PageUnaccepted(buddy) on every buddy size > while merging. Needing to check PageUnaccepted() during the merge is fallout from moving the acceptance to post_alloc_hook(). I _think_ an earlier version of this did page acceptance under the zone lock, closer to where the page comes off the 2M/4M lists. But, page acceptance is horribly slow, so I asked Kirill to move it out from under the zone lock. Doing it in post_alloc_hook() (after the zone lock is dropped) makes a lot of sense since we do zeroing in there and zeroing is also nice and slow. But, post_alloc_hook() is long after the 2M page has been split and that means that we have to deal with potentially unaccepted pages during merges. I think there are three basic options: 1. This patch: Do acceptance after the zone lock is dropped and deal with mixed-acceptance merges 2. Do acceptance under the zone lock as pages come off the 2M/4M lists, but before the page is split. 3. Pull the page off the 2M/4M lists, drop the zone lock, accept it, then put it back. I'm not sure any of those other options are better.
