All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Alistair Popple <apopple@nvidia.com>,
	Peter Xu <peterx@redhat.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Konstantin Khlebnikov <koct9i@gmail.com>,
	Bin Wang <wangbin224@huawei.com>, Yang Shi <shy828301@gmail.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] mm, pagemap: expose hwpoison entry
Date: Wed, 27 Oct 2021 08:27:36 +0900	[thread overview]
Message-ID: <20211026232736.GA2704541@u2004> (raw)
In-Reply-To: <20211004143228.GA1545442@u2004>

On Mon, Oct 04, 2021 at 11:32:28PM +0900, Naoya Horiguchi wrote:
> On Mon, Oct 04, 2021 at 01:55:30PM +0200, David Hildenbrand wrote:
> > On 04.10.21 13:50, Naoya Horiguchi wrote:
...
> > >
> > > Hwpoison entry for hugepage is also exposed by this patch. The below
> > > example shows how pagemap is visible in the case where a memory error
> > > hit a hugepage mapped to a process.
> > >
> > >      $ ./page-types --no-summary --pid $PID --raw --list --addr 0x700000000+0x400
> > >      voffset offset  len     flags
> > >      700000000       12fa00  1       ___U_______Ma__H_G_________________f_______1
> > >      700000001       12fa01  1ff     ___________Ma___TG_________________f_______1
> > >      700000200       12f800  1       __________B________X_______________f______w_
> > >      700000201       12f801  1       ___________________X_______________f______w_   // memory failure hit this page
> > >      700000202       12f802  1fe     __________B________X_______________f______w_
> > >
> > > The entries with both of "X" flag (hwpoison flag) and "w" flag (swap
> > > flag) are considered as hwpoison entries.  So all pages in 2MB range
> > > are inaccessible from the process.  We can get actual error location
> > > by page-types in physical address mode.
> > >
> > >      $ ./page-types --no-summary --addr 0x12f800+0x200 --raw --list
> > >      offset  len     flags
> > >      12f800  1       __________B_________________________________
> > >      12f801  1       ___________________X________________________
> > >      12f802  1fe     __________B_________________________________
> > >
> > > Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
> > > ---
> > >   fs/proc/task_mmu.c      | 41 ++++++++++++++++++++++++++++++++---------
> > >   include/linux/swapops.h | 13 +++++++++++++
> > >   tools/vm/page-types.c   |  7 ++++++-
> > >   3 files changed, 51 insertions(+), 10 deletions(-)
> >
> >
> > Please also update the documentation located at
> >
> > Documentation/admin-guide/mm/pagemap.rst
>
> I will do this in the next post.

Reading the document, I found that swap type is already exported so we
could identify hwpoison entry with it (without new PM_HWPOISON bit).
One problem is that the format of swap types (like SWP_HWPOISON) depends
on a few config macros like CONFIG_DEVICE_PRIVATE and CONFIG_MIGRATION,
so we also need to export how the swap type field is interpreted.

I thought of adding new interfaces for example under /sys/kernel/mm/swap/type_format/,
which shows info like below (assuming that all CONFIG_{DEVICE_PRIVATE,MIGRATION,MEMORY_FAILURE}
is enabled):

  $ ls /sys/kernel/mm/swap/type_format/
  hwpoison
  migration_read
  migration_write
  device_write
  device_read
  device_exclusive_write
  device_exclusive_read
  
  $ cat /sys/kernel/mm/swap/type_format/hwpoison
  25
  
  $ cat /sys/kernel/mm/swap/type_format/device_write
  28

Does it make sense or any better approach?

Thanks,
Naoya Horiguchi

  reply	other threads:[~2021-10-26 23:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 11:50 [PATCH v1] mm, pagemap: expose hwpoison entry Naoya Horiguchi
2021-10-04 11:55 ` David Hildenbrand
2021-10-04 14:32   ` Naoya Horiguchi
2021-10-26 23:27     ` Naoya Horiguchi [this message]
2021-10-27  2:09       ` Peter Xu
2021-10-27  6:45         ` Naoya Horiguchi
2021-10-27  7:02           ` Peter Xu
2021-10-27  7:15             ` David Hildenbrand
2021-10-04 20:17 ` kernel test robot
2021-10-04 20:17   ` kernel test robot
2021-10-05  2:53 ` kernel test robot
2021-10-05  2:53   ` kernel test robot
2021-10-13  2:49 ` Peter Xu
2021-10-14 13:36   ` Naoya Horiguchi
2021-10-14 23:32     ` Peter Xu

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=20211026232736.GA2704541@u2004 \
    --to=naoya.horiguchi@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=david@redhat.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=peterx@redhat.com \
    --cc=shy828301@gmail.com \
    --cc=wangbin224@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.