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 <mho...@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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
