[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Mar 2020 09:34:51 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Matthew Wilcox <willy@...radead.org>,
linux-fsdevel@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>
Cc: linux-kernel@...r.kernel.org,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/5] Simplify /proc/$pid/maps implementation
On 2/29/20 5:59 PM, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@...radead.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@...e.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
>
Powered by blists - more mailing lists