[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190718144459.7a20ac42ee16e093bdfcfab4@linux-foundation.org>
Date: Thu, 18 Jul 2019 14:44:59 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Yang Shi <yang.shi@...ux.alibaba.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, hughd@...gle.com,
kirill.shutemov@...ux.intel.com, mhocko@...e.com,
rientjes@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [v3 PATCH 2/2] mm: thp: fix false negative of shmem vma's THP
eligibility
On Wed, 19 Jun 2019 09:28:42 -0700 Yang Shi <yang.shi@...ux.alibaba.com> wrote:
> > Sorry for replying rather late, and not in the v2 thread, but unlike
> > Hugh I'm not convinced that we should include vma size/alignment in the
> > test for reporting THPeligible, which was supposed to reflect
> > administrative settings and madvise hints. I guess it's mostly a matter
> > of personal feeling. But one objective distinction is that the admin
> > settings and madvise do have an exact binary result for the whole VMA,
> > while this check is more fuzzy - only part of the VMA's span might be
> > properly sized+aligned, and THPeligible will be 1 for the whole VMA.
>
> I think THPeligible is used to tell us if the vma is suitable for
> allocating THP. Both anonymous and shmem THP checks vma size/alignment
> to decide to or not to allocate THP.
>
> And, if vma size/alignment is not checked, THPeligible may show "true"
> for even 4K mapping. This doesn't make too much sense either.
This discussion seems rather inconclusive. I'll merge up the patchset
anyway. Vlastimil, if you think some changes are needed here then
please let's get them sorted out over the next few weeks?
Powered by blists - more mailing lists