Re: [PATCH 04/11] lib/dlock-list: Make sibling CPUs share the same linked list
On Wed, Dec 06, 2023 at 05:05:33PM +1100, Dave Chinner wrote: > From: Waiman Long > > 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. Probably a dumb question, but... "available" != "possible"; the code actually goes for the latter, which avoids nasty questions about CPU hotplug interations. Is the sibling relation on CPUs unchanging on CPU hotplug?
Re: [PATCH 04/11] lib/dlock-list: Make sibling CPUs share the same linked list
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 > > > > 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 da...@fromorbit.com
Re: [PATCH 04/11] lib/dlock-list: Make sibling CPUs share the same linked list
On Wed, Dec 06, 2023 at 05:05:33PM +1100, Dave Chinner wrote: > From: Waiman Long > > 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 it looks like there's some duplication of this with list_lru functionality - similar list-sharded-by-node idea. 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? 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. But it's nice and small, and I'd like to use it elsewhere. Reviewed-by: Kent Overstreet
Re: [PATCH 04/11] lib/dlock-list: Make sibling CPUs share the same linked list
On Wed, Dec 06, 2023 at 05:05:33PM +1100, Dave Chinner wrote: > From: Waiman Long > > 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. > > Signed-off-by: Waiman Long > Reviewed-by: Jan Kara We badly need this done in a more generic way. Besides shared caches, I've done a bunch of percpu algorithms where "amount of x stranded on percpu lists" is a major consideration and this would be preferable over percpu lists (including in fs/aio.c).
