On Wed, 31 May 2023 16:39:34 +0530 Charan Teja Kalla <quic_charante@xxxxxxxxxxx> wrote: > A folio turns into a Workingset during: > 1) shrink_active_list() placing the folio from active to inactive list. > 2) When a workingset transition is happening during the folio refault. > > And when Workingset is set on a folio, PSI for memory can be accounted > during a) That folio is being reclaimed and b) Refault of that folio. > > There exists clients who can do the proactive reclaim using the system > calls like madvise(), whose folios can be safely treated as inactive > folios assuming the client knows that these folios are not needed in the > near future thus wanted to reclaim them. For such folios psi is not > accounted uniformly: > a) A folio started at inactive and moved to active as part of accesses. > Workingset is absent on the folio thus madvise(MADV_PAGEOUT) don't > account such folios for PSI. > > b) When the same folio transition from inactive->active and then to > inactive through shrink_active_list(). Workingset is set on the folio > thus madvise(MADV_PAGEOUT) account such folios for PSI. > > c) When the same folio is part of active list directly as a result of > folio refault and this was a workingset folio prior to eviction. > Workingset is set on the folio thus madvise(MADV_PAGEOUT) account such > folios for PSI. > > As said about the MADV_PAGEOUT on a folio is accounted in b) and c) but > not in a) which is inconsistent. Remove this inconsistency by always not > considering the PSI for folios that are getting reclaimed through > madvise(MADV_PAGEOUT) by clearing the Workingset on a folio. This > consistency of clearing the workingset was chosen under the assumption > that client knows these folios are not in active use thus reclaiming > them hence not eligible as workingset folios. Probably it is the same > reason why workingset is not set on a folio through MADV_COLD but during > the shrink_active_list() though both the actions make the folio put onto > the inactive list. > > This patch is tested on Android, Snapdragon SoC with 8Gb RAM, 4GB swap > mounted on zram which has 2GB of backingdev. The test case involved > launching some memory hungry apps in an order and do the proactive > reclaim for the app that went to background using madvise(MADV_PAGEOUT). > We are seeing ~40% less total values of psi mem some and full when this > patch is combined with [1]. Does this accounting inaccuracy have any perceptible runtime effects?
