On Thu, Dec 07, 2023 at 12:42:59AM -0500, Kent Overstreet wrote: > On Wed, Dec 06, 2023 at 05:05:33PM +1100, Dave Chinner wrote: > > From: Waiman Long <longman@xxxxxxxxxx> > > > > The dlock list needs one list for each of the CPUs available. However, > > for sibling CPUs, they are sharing the L2 and probably L1 caches > > too. As a result, there is not much to gain in term of avoiding > > cacheline contention while increasing the cacheline footprint of the > > L1/L2 caches as separate lists may need to be in the cache. > > > > This patch makes all the sibling CPUs share the same list, thus > > reducing the number of lists that need to be maintained in each > > dlock list without having any noticeable impact on performance. It > > also improves dlock list iteration performance as fewer lists need > > to be iterated. > > Seems Waiman was missed on the CC Oops, I knew I missed someone important.... > it looks like there's some duplication of this with list_lru > functionality - similar list-sharded-by-node idea. For completely different reasons. The list_lru is aligned to the mm zone architecture which only partitions memory management accounting and scanning actions down into NUMA nodes. It's also a per-node ordered list (LRU), and it has intricate locking semantics that expose internal list locks to external isolation functions that can be called whilst a lock protected traversal is in progress. Further, we have to consider that list-lru is tightly tied to memcgs. For a single NUMA- and memcg- aware list-lru, there is actually nr_memcgs * nr_nodes LRUs per list. The memory footprint of a superblock list_lru gets quite gigantic when we start talking about machines with hundreds of nodes running tens of thousands of containers each with tens of superblocks. That's the biggest problem with using a more memory expensive structure for the list_lru - we're talking gigabytes of memory just for the superblock shrinker tracking structure overhead on large machines. This was one of the reasons why we haven't tried to make list_lrus any more fine-grained that it absolutely needs to be to provide acceptible scalability. > list_lru does the sharding by page_to_nid() of the item, which > saves a pointer and allows just using a list_head in the item. > OTOH, it's less granular than what dlock-list is doing? Sure, but there's a lot more to list_lrus than it being a "per-node list". OTOH, dlock_list is really nothing more than a "per-cpu list".... > I think some attempt ought to be made to factor out the common > ideas hear; perhaps reworking list_lru to use this thing, and I > hope someone has looked at the page_nid idea vs. dlock_list using > the current core. I certainly have, and I haven't been able to justify the additional memory footprint of a dlock_list over the existing per-node lists. That may change given that XFS appears to be on the theshold of per-node list-lru lock breakdown at 64 threads, but there's a lot more to consider from a system perspective here than just inode/dentry cache scalability.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
