Re: [PATCH v2 00/11] mm: Teach memory_failure() about ZONE_DEVICE pages

From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Michal Hocko" <mhocko@kernel.org>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"Tony Luck" <tony.luck@intel.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, "X86 ML" <x86@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Christoph Hellwig" <hch@lst.de>,
	"Ross Zwisler" <ross.zwisler@linux.intel.com>,
	"Matthew Wilcox" <mawilcox@microsoft.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Souptick Joarder" <jrdr.linux@gmail.com>,
	"Linux MM" <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"Andi Kleen" <ak@linux.intel.com>
Subject: Re: [PATCH v2 00/11] mm: Teach memory_failure() about ZONE_DEVICE pages
Date: Tue, 12 Jun 2018 01:50:26 +0000	[thread overview]
Message-ID: <20180612015025.GA25302@hori1.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <CAPcyv4hnPRk0hTGctHB4tBnyL_27x3DwPUVwhZ+L7c-=1Xdf6Q@mail.gmail.com>

On Mon, Jun 11, 2018 at 08:19:54AM -0700, Dan Williams wrote:
> On Mon, Jun 11, 2018 at 7:56 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Mon 11-06-18 07:44:39, Dan Williams wrote:
> > [...]
> >> I'm still trying to understand the next level of detail on where you
> >> think the design should go next? Is it just the HWPoison page flag?
> >> Are you concerned about supporting greater than PAGE_SIZE poison?
> >
> > I simply do not want to check for HWPoison at zillion of places and have
> > each type of page to have some special handling which can get wrong very
> > easily. I am not clear on details here, this is something for users of
> > hwpoison to define what is the reasonable scenarios when the feature is
> > useful and turn that into a feature list that can be actually turned
> > into a design document. See the different from let's put some more on
> > top approach...
> >
> 
> So you want me to pay the toll of writing a design document justifying
> all the existing use cases of HWPoison before we fix the DAX bugs, and
> the design document may or may not result in any substantive change to
> these patches?
> 
> Naoya or Andi, can you chime in here?

memory_failure() does 3 things:

 - unmapping the error page from processes using it,
 - isolating the error page with PageHWPoison,
 - logging/reporting.

The unmapping part and the isolating part are quite page type dependent,
so this seems to me hard to do them in generic manner (so supporting new
page type always needs case specific new code.)
But I agree that we can improve code and document to help developers add
support for new page type.

About documenting, the content of Documentation/vm/hwpoison.rst is not
updated since 2009, so some update with design thing might be required.
My current thought about update items are like this:

  - detailing general workflow,
  - adding some about soft offline,
  - guideline for developers to support new type of memory,
  (- and anything helpful/requested.)

Making code more readable/self-descriptive is helpful, though I'm
not clear now about how.

Anyway I'll find time to work on this, while now I'm testing the dax
support patches and fixing a bug I found recently.

Thanks,
Naoya Horiguchi