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

[Jane Chu <jane.chu@oracle.com>]

On 6/11/2018 6:50 PM, Naoya Horiguchi wrote:

> 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.

Thank you. Maybe it's already on your mind, but just in case. When you update the
document, would you add the characteristics of pmem error handling in that
   . UE/poison can be repaired until the wear and tear reaches a max level
   . many user applications mmap the entire capacity, leaving no spare pages
     for swapping (unlike the volatile memory UE handling)
   . the what-you-see-is-what-you-get nature
?
Regarding HWPOISON redesign, a nagging thought is that a memory UE typically indicts
a very small blast radius, less than 4KB.  But it seems that the larger the page size,
the greater the 'penalty' in terms of how much memory would end up being offlined.
If there a way to be frugal?

Thanks!
-jane

>
> Thanks,
> Naoya Horiguchi
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm