On Mon, Jan 09, 2023 at 03:22:29PM +0800, Yin Fengwei wrote: > The idea of the multiple consecutive page (abbr as "mcpage") is using > collection of physical contiguous 4K page other than huge page for > anonymous mapping. This is what folios are for. You have an interesting demonstration here that shows that moving to larger folios for anonymous memory is worth doing (thank you!) but you're missing several of the advantages of folios by going off and doing your own thing. > The size of mcpage can be configured. The default value of 16K size is > just picked up arbitrarily. User should choose the value according to the > result of tuning their workload with different mcpage size. Uh, no. We don't do these kinds of config options any more (or boot-time options as you mention later). The size of a folio allocated for a given VMA should be adaptive based on observing how the program is using memory. There will likely be many different sizes of folio present in a given VMA. > To have physical contiguous pages, high order pages is allocated (order > is calculated according to mcpage size). Then the high order page will > be split. By doing this, each sub page of mcpage is just normal 4K page. > The current kernel page management infrastructure is applied to "mc" > pages without any change. This is somewhere that you're losing an advantage of folios. By keeping all the pages together, they get managed as a single unit. That shrinks the length of the LRU list and reduces lock contention. It also reduces the number of cache lines which are modified as, eg, we only need to keep track of one dirty bit for many pages. > To reduce the page fault number, multiple page table entries are populated > in one page fault with sub pages pfn of mcpage. This also brings a little > bit cost of memory consumption. That needs to be done for folios. It's a long way down my todo list, so if you wanted to take it on, it would be very much appreciated!
