On 02/01/2018 04:44 AM, Matthew Wilcox wrote:
On Wed, Jan 31, 2018 at 11:44:29PM -0500, Daniel Jordan wrote:
I'd like to propose a discussion of lru_lock scalability on the mm track. Since this is similar to Laurent Dufour's mmap_sem topic, it might make sense to discuss these around the same time.
On large systems, lru_lock is one of the hottest locks in the kernel, showing up on many memory-intensive benchmarks such as decision support. It also inhibits scalability in many of the mm paths that could be parallelized, such as freeing pages during exit/munmap and inode eviction.
I'd like to discuss the following two ways of solving this problem, as well as any other approaches or ideas people have.
Something I've been thinking about is changing the LRU from an embedded
list_head to an external data structure that I call the XQueue.
It's based on the XArray, but is used like a queue; pushing items onto
the end of the queue and popping them off the beginning. You can also
remove items from the middle of the queue.
Removing items from the list usually involves dirtying three cachelines.
With the XQueue, you'd only dirty one. That's going to reduce lock
hold time. There may also be opportunities to reduce lock hold time;
removal and addition can be done in parallel as long as there's more
than 64 entries between head and tail of the list.
The downside is that adding to the queue would require memory allocation.
And I don't have time to work on it at the moment.
I like the idea of touching fewer cachelines.
I looked through your latest XArray series (v6). Am I understanding it correctly that a removal (xa_erase) is an exclusive operation within one XArray, i.e. that only one thread can do this at once? Not sure how XQueue would implement removal though, so the answer might be different for it.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
