Chris Li <chrisl@xxxxxxxxxx> writes: > Hi Ying, > > On Tue, Apr 23, 2024 at 7:26 PM Huang, Ying <ying.huang@xxxxxxxxx> wrote: >> >> Hi, Matthew, >> >> Matthew Wilcox <willy@xxxxxxxxxxxxx> writes: >> >> > On Mon, Apr 22, 2024 at 03:54:58PM +0800, Huang, Ying wrote: >> >> Is it possible to add "start_offset" support in xarray, so "index" >> >> will subtract "start_offset" before looking up / inserting? >> > >> > We kind of have that with XA_FLAGS_ZERO_BUSY which is used for >> > XA_FLAGS_ALLOC1. But that's just one bit for the entry at 0. We could >> > generalise it, but then we'd have to store that somewhere and there's >> > no obvious good place to store it that wouldn't enlarge struct xarray, >> > which I'd be reluctant to do. >> > >> >> Is it possible to use multiple range locks to protect one xarray to >> >> improve the lock scalability? This is why we have multiple "struct >> >> address_space" for one swap device. And, we may have same lock >> >> contention issue for large files too. >> > >> > It's something I've considered. The issue is search marks. If we delete >> > an entry, we may have to walk all the way up the xarray clearing bits as >> > we go and I'd rather not grab a lock at each level. There's a convenient >> > 4 byte hole between nr_values and parent where we could put it. >> > >> > Oh, another issue is that we use i_pages.xa_lock to synchronise >> > address_space.nrpages, so I'm not sure that a per-node lock will help. >> >> Thanks for looking at this. >> >> > But I'm conscious that there are workloads which show contention on >> > xa_lock as their limiting factor, so I'm open to ideas to improve all >> > these things. >> >> I have no idea so far because my very limited knowledge about xarray. > > For the swap file usage, I have been considering an idea to remove the > index part of the xarray from swap cache. Swap cache is different from > file cache in a few aspects. > For one if we want to have a folio equivalent of "large swap entry". > Then the natural alignment of those swap offset on does not make > sense. Ideally we should be able to write the folio to un-aligned swap > file locations. > > The other aspect for swap files is that, we already have different > data structures organized around swap offset, swap_map and > swap_cgroup. If we group the swap related data structure together. We > can add a pointer to a union of folio or a shadow swap entry. The shadow swap entry may be freed. So we need to prepare for that. And, in current design, only swap_map[] is allocated if the swap space isn't used. That needs to be considered too. > We can use atomic updates on the swap struct member or breakdown the > access lock by ranges just like swap cluster does. The swap code uses xarray in a simple way. That gives us opportunity to optimize. For example, it makes it easy to use multiple xarray instances for one swap device. > I want to discuss those ideas in the upcoming LSF/MM meet up as well. Good! -- Best Regards, Huang, Ying
