* Re: [PATCH 0/5] Simplify /proc/$pid/maps implementation
[not found] <20200229165910.24605-1-willy@infradead.org>
@ 2020-03-03 8:34 ` Vlastimil Babka
0 siblings, 0 replies; only message in thread
From: Vlastimil Babka @ 2020-03-03 8:34 UTC (permalink / raw)
To: Matthew Wilcox, linux-fsdevel, Alexey Dobriyan
Cc: linux-kernel, linux-mm@kvack.org
On 2/29/20 5:59 PM, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Re: subject, it's not only maps, but also smaps, smaps_rollu, numa_maps
> Back in 2005, we merged a patch from Akamai that sped up /proc/$pid/maps
> by using f_version to stash the user virtual address that we'd just
> displayed. That wasn't necessary; we can just use the private *ppos for
> the same purpose. There have also been some other odd choices made over
> the years that use the seq_file infrastructure in some non-idiomatic ways.
>
> Tested by using 'dd' with various different 'bs=' parameters to check that
> calling ->start, ->stop and ->next at various offsets work as expected.
>
> Matthew Wilcox (Oracle) (5):
> proc: Inline vma_stop into m_stop
> proc: remove m_cache_vma
> proc: Use ppos instead of m->version
> seq_file: Remove m->version
> proc: Inline m_next_vma into m_next
For all of them:
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thanks!
> fs/proc/task_mmu.c | 95 +++++++++++++---------------------------
> fs/seq_file.c | 28 ------------
> include/linux/seq_file.h | 1 -
> 3 files changed, 31 insertions(+), 93 deletions(-)
>
> base-commit: d5226fa6dbae0569ee43ecfc08bdcd6770fc4755
>
^ permalink raw reply [flat|nested] only message in thread