On 8/5/22 16:41, Dave Hansen wrote: > 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. Rather not, as acceptance can be slow and we shouldn't hog the zone lock while doing it. > 3. Pull the page off the 2M/4M lists, drop the zone lock, accept it, > then put it back. Worth trying, IMHO. Perhaps easier to manage if the lists are distinct from the normal ones, as I suggested. > I'm not sure any of those other options are better.
