On Thu, Jan 28, 2021 at 02:57:10PM +0100, Michal Hocko wrote: > On Thu 28-01-21 13:45:12, Mel Gorman wrote: > [...] > > So mostly this is down to the number of times SLUB calls into the page > > allocator which only caches order-0 pages on a per-cpu basis. I do have > > a prototype for a high-order per-cpu allocator but it is very rough -- > > high watermarks stop making sense, code is rough, memory needed for the > > pcpu structures quadruples etc. > > Thanks this is really useful. But it really begs a question whether this > is a general case or more an exception. And as such maybe we want to > define high throughput caches which would gain a higher order pages to > keep pace with allocation and reduce the churn or deploy some other > techniques to reduce the direct page allocator involvement. I don't think we want to define "high throughput caches" because it'll be workload dependant and a game of whack-a-mole. If the "high throughput cache" is a kmalloc cache for some set of workloads and one of the inode caches or dcaches for another one, there will be no setting that is universally good. -- Mel Gorman SUSE Labs
