Zhaoyu Liu <liuzhaoyu.zackary@xxxxxxxxxxxxx> writes: > On Tue, Apr 09, 2024 at 09:07:29AM +0800, Huang, Ying wrote: >> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: >> >> > On Mon, 8 Apr 2024 20:14:39 +0800 Zhaoyu Liu <liuzhaoyu.zackary@xxxxxxxxxxxxx> wrote: >> > >> >> Based on qemu arm64 - latest kernel + 100M memory + 1024M swapfile. >> >> Create 1G anon mmap and set it to shared, and has two processes >> >> randomly access the shared memory. When they are racing on swap cache, >> >> on average, each "alloc_pages_mpol + swapcache_prepare + folio_put" >> >> took about 1475 us. >> > >> > And what effect does this patch have upon the measured time? ANd upon >> > overall runtime? >> >> And the patch will cause increased lock contention, please test with >> more processes and perhaps HDD swap device too. > > Hi Ying, > > Thank you for your suggestion. > It may indeed cause some lock contention, as mentioned by Kairui before. > > If so, is it recommended? > --- > unsigned char swap_map, mapcount, hascache; > ... > /* Return raw data of the si->swap_map[offset] */ > swap_map = __swap_map(si, entry); > mapcount = swap_map & ~SWAP_HAS_CACHE; > if (!mapcount && swap_slot_cache_enabled) > ... > hascache = swap_map & SWAP_HAS_CACHE; > /* Could judge that it's being added to swap cache with high probability */ > if (mapcount && hascache) > goto skip_alloc; > ... > --- > In doing so, there is no additional use of locks. Yes. This can remove the lock-contention. But, you need to prove that it's necessary in the first place. -- Best Regards, Huang, Ying >> >> So skip page allocation if SWAP_HAS_CACHE was set, just >> >> schedule_timeout_uninterruptible and continue to acquire page >> >> via filemap_get_folio() from swap cache, to speedup >> >> __read_swap_cache_async.
