On Tue, Aug 20, 2019 at 03:03:55PM +0800, Wanpeng Li wrote:
> Cc Mel Gorman, Kirill, Dave Hansen,
> On Tue, 11 Jun 2019 at 07:51, Naoya Horiguchi
> wrote:
> >
> > On Wed, May 29, 2019 at 04:31:01PM -0700, Mike Kravetz wrote:
> > > On 5/28/19 2:49 AM, Wanp
tual address range
> > which is 2MB/4KB page granularity, also split the KVM MMU 1GB SPTE
> > into 2MB/4KB and mark the offensive SPTE w/ a hwpoison flag, a sigbus
> > will be delivered to VM at page fault next time for the offensive
> > SPTE. Is this proposal acceptable?
>
> I am not sure of the error handling design, but this does sound reasonable.
I agree that that's better.
> That block of code which potentially dissolves a huge page on memory error
> is hard to understand and I'm not sure if that is even the 'normal'
> functionality. Certainly, we would hate to waste/poison an entire 1G page
> for an error on a small subsection.
Yes, that's not practical, so we need at first establish the code base for
2GB hugetlb splitting and then extending it to 1GB next.
Thanks,
Naoya Horiguchi
ersion. This split helps
> in doing that nicely.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Naoya Horiguchi
On Mon, Apr 17, 2017 at 10:41:40PM +0530, Aneesh Kumar K.V wrote:
> The right interface to use to set a hugetlb pte entry is set_huge_pte_at. Use
> that instead of set_pte_at.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Naoya Horiguchi
On Mon, Apr 17, 2017 at 10:41:42PM +0530, Aneesh Kumar K.V wrote:
> We will be using this later from the ppc64 code. Change the return type to
> bool.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Naoya Horiguchi
