From: Matthew Wilcox <willy@infradead.org>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: linux-mm@kvack.org, "Matthew Wilcox" <mawilcox@microsoft.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
"Christoph Lameter" <cl@linux.com>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
"Pekka Enberg" <penberg@kernel.org>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Jérôme Glisse" <jglisse@redhat.com>
Subject: Re: [PATCH v6 17/17] mm: Distinguish VMalloc pages
Date: Tue, 22 May 2018 10:58:36 -0700 [thread overview]
Message-ID: <20180522175836.GB1237@bombadil.infradead.org> (raw)
In-Reply-To: <74e9bf39-ae17-cc00-8fca-c34b75675d49@virtuozzo.com>
On Tue, May 22, 2018 at 07:10:52PM +0300, Andrey Ryabinin wrote:
> On 05/18/2018 10:45 PM, Matthew Wilcox wrote:
> > From: Matthew Wilcox <mawilcox@microsoft.com>
> >
> > For diagnosing various performance and memory-leak problems, it is helpful
> > to be able to distinguish pages which are in use as VMalloc pages.
> > Unfortunately, we cannot use the page_type field in struct page, as
> > this is in use for mapcount by some drivers which map vmalloced pages
> > to userspace.
> >
> > Use a special page->mapping value to distinguish VMalloc pages from
> > other kinds of pages. Also record a pointer to the vm_struct and the
> > offset within the area in struct page to help reconstruct exactly what
> > this page is being used for.
>
> This seems useless. page->vm_area and page->vm_offset are never used.
> There are no follow up patches which use this new information 'For diagnosing various performance and memory-leak problems',
> and no explanation how is it can be used in current form.
Right now, it's by-hand. tools/vm/page-types.c will tell you which pages
are allocated to VMalloc. Many people use kernel debuggers, crashdumps
and similar to examine the kernel's memory. Leaving these breadcrumbs
is helpful, and those fields simply weren't in use before.
> Also, this patch breaks code like this:
> if (mapping = page_mapping(page))
> // access mapping
Example of broken code, please? Pages allocated from the page allocator
with alloc_page() come with page->mapping == NULL. This code snippet
would not have granted access to vmalloc pages before.
next prev parent reply other threads:[~2018-05-22 17:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 19:45 [PATCH v6 00/17] Rearrange struct page Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 01/17] s390: Use _refcount for pgtables Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 02/17] mm: Split page_type out from _mapcount Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 03/17] mm: Mark pages in use for page tables Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 04/17] mm: Switch s_mem and slab_cache in struct page Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 05/17] mm: Move 'private' union within " Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 06/17] mm: Move _refcount out of struct page union Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 07/17] mm: Combine first three unions in struct page Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 08/17] mm: Use page->deferred_list Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 09/17] mm: Move lru union within struct page Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 10/17] mm: Combine LRU and main union in " Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 11/17] mm: Improve struct page documentation Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 12/17] mm: Add pt_mm to struct page Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 13/17] mm: Add hmm_data " Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 14/17] slab,slub: Remove rcu_head size checks Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 15/17] slub: Remove kmem_cache->reserved Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 16/17] slub: Remove 'reserved' file from sysfs Matthew Wilcox
2018-05-18 19:45 ` [PATCH v6 17/17] mm: Distinguish VMalloc pages Matthew Wilcox
2018-05-22 16:10 ` Andrey Ryabinin
2018-05-22 17:58 ` Matthew Wilcox [this message]
2018-05-22 19:49 ` Andrew Morton
2018-05-22 19:57 ` Andrey Ryabinin
2018-05-22 20:19 ` Matthew Wilcox
2018-05-22 20:48 ` Andrew Morton
2018-05-22 21:45 ` Matthew Wilcox
2018-05-22 23:02 ` Andrew Morton
2018-05-23 6:36 ` Michal Hocko
2018-05-23 6:34 ` Michal Hocko
2018-05-23 9:14 ` Andrey Ryabinin
2018-05-23 9:25 ` Michal Hocko
2018-05-23 9:28 ` Andrey Ryabinin
2018-05-23 9:52 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180522175836.GB1237@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=cl@linux.com \
--cc=dave.hansen@linux.intel.com \
--cc=jglisse@redhat.com \
--cc=jiangshanlai@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mawilcox@microsoft.com \
--cc=penberg@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox