Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH v4 0/3] Try to release mmap_lock temporarily in smaps_rollup
@ 2020-08-18  1:58 Chinwen Chang
  2020-08-18  1:58 ` [PATCH v4 1/3] mmap locking API: add mmap_lock_is_contended() Chinwen Chang
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Chinwen Chang @ 2020-08-18  1:58 UTC (permalink / raw)
  To: Matthias Brugger, Michel Lespinasse, Andrew Morton,
	Vlastimil Babka, Daniel Jordan, Davidlohr Bueso, Chinwen Chang,
	Alexey Dobriyan, Matthew Wilcox (Oracle),
	Jason Gunthorpe, Steven Price, Song Liu, Jimmy Assarsson,
	Huang Ying, Daniel Kiss, Laurent Dufour
  Cc: linux-kernel, linux-arm-kernel, linux-mediatek, linux-fsdevel,
	wsd_upstream

Recently, we have observed some janky issues caused by unpleasantly long
contention on mmap_lock which is held by smaps_rollup when probing large
processes. To address the problem, we let smaps_rollup detect if anyone
wants to acquire mmap_lock for write attempts. If yes, just release the
lock temporarily to ease the contention.

smaps_rollup is a procfs interface which allows users to summarize the
process's memory usage without the overhead of seq_* calls. Android uses it
to sample the memory usage of various processes to balance its memory pool
sizes. If no one wants to take the lock for write requests, smaps_rollup
with this patch will behave like the original one.

Although there are on-going mmap_lock optimizations like range-based locks,
the lock applied to smaps_rollup would be the coarse one, which is hard to
avoid the occurrence of aforementioned issues. So the detection and
temporary release for write attempts on mmap_lock in smaps_rollup is still
necessary.

Change since v1:
- If current VMA is freed after dropping the lock, it will return
- incomplete result. To fix this issue, refine the code flow as
- suggested by Steve. [1]

Change since v2:
- When getting back the mmap lock, the address where you stopped last
- time could now be in the middle of a vma. Add one more check to handle
- this case as suggested by Michel. [2]

Change since v3:
- last_stopped is easily confused with last_vma_end. Replace it with
- a direct call to smap_gather_stats(vma, &mss, last_vma_end) as
- suggested by Steve. [3]

[1] https://lore.kernel.org/lkml/bf40676e-b14b-44cd-75ce-419c70194783@arm.com/
[2] https://lore.kernel.org/lkml/CANN689FtCsC71cjAjs0GPspOhgo_HRj+diWsoU1wr98YPktgWg@mail.gmail.com/
[3] https://lore.kernel.org/lkml/db0d40e2-72f3-09d5-c162-9c49218f128f@arm.com/


Chinwen Chang (3):
  mmap locking API: add mmap_lock_is_contended()
  mm: smaps*: extend smap_gather_stats to support specified beginning
  mm: proc: smaps_rollup: do not stall write attempts on mmap_lock

 fs/proc/task_mmu.c        | 96 +++++++++++++++++++++++++++++++++++----
 include/linux/mmap_lock.h |  5 ++
 2 files changed, 92 insertions(+), 9 deletions(-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-08-19  7:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-18  1:58 [PATCH v4 0/3] Try to release mmap_lock temporarily in smaps_rollup Chinwen Chang
2020-08-18  1:58 ` [PATCH v4 1/3] mmap locking API: add mmap_lock_is_contended() Chinwen Chang
2020-08-18  1:58 ` [PATCH v4 2/3] mm: smaps*: extend smap_gather_stats to support specified beginning Chinwen Chang
2020-08-18  1:58 ` [PATCH v4 3/3] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock Chinwen Chang
2020-08-19  7:37   ` Steven Price

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).