Re: [LSF/MM TOPIC] lru_lock scalability

[Matthew Wilcox <willy@infradead.org>]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>