On Wed 12-03-25 10:47:12, Luis Chamberlain wrote: > On Tue, Feb 11, 2025 at 12:13:18PM +1100, Dave Chinner wrote: > > Should we be looking towards using a subset of the existing list_lru > > functionality for writeback contexts here? i.e. create a list_lru > > object with N-way scalability, allow the fs to provide an > > inode-number-to-list mapping function, and use the list_lru > > interfaces to abstract away everything physical and cgroup related > > for tracking dirty inodes? > > > > Then selecting inodes for writeback becomes a list_lru_walk() > > variant depending on what needs to be written back (e.g. physical > > node, memcg, both, everything that is dirty everywhere, etc). > > I *suspect* you're referring to abstracting or sharing the sharding > to numa node functionality of list_lru so we can, divide objects > to numa nodes in similar ways for different use cases? > > Because list_lru is about reclaim, not writeback, but from my reading > the list_lru sharding to numa nodes was the golden nugget to focus on. Dave was speaking of list_lru mostly as an example how we have a structure that is both memcg aware and has N-way parallelism built in it (for NUMA nodes). For writeback we need something similar - we already have cgroup awareness and now you want to add N-way parallelism. So the idea was that we could possibly create a generic structure supporting this usable for both. But details matter here for what ends up being practical... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
