Re: kernel BUG in page_add_anon_rmap

[Hillf Danton <hdanton@sina.com>]

On Mon, 30 Jan 2023 16:11:58 +0000 Matthew Wilcox <willy@infradead.org>
> On Sat, Jan 28, 2023 at 10:49:31PM -0800, Hugh Dickins wrote:
> > I guess it will turn out not to be relevant to this particular syzbug,
> > but what do we expect an mbind() of just 0x1000 of a THP to do?
> > 
> > It's a subject I've wrestled with unsuccessfully in the past: I found
> > myself arriving at one conclusion (split THP) in one place, and a contrary
> > conclusion (widen range) in another place, and never had time to work out
> > one unified answer.
> > 
> > So I do wonder what pte replaces the migration entry when the bug here
> > is fixed: is it a pte pointing into the THP as before, in which case
> > what was the point of "migration"? is it a Copy-On-Bind page?
> > or has the whole THP been migrated?
> 
> I have an Opinion!
> 
> The important thing about THP (IMO) is the Transparency part.
> Applications don't need to do anything special to get memory managed
> in larger chunks, the only difference is in performance.  That is, they
> get better performance if the kernel can do it, and thinks it worthwhile.
> 
> The tradeoff with THP is that we treat all memory in this 2MB chunk the
> same way; we track its dirtiness and age as a single thing (position
> on LRU, etc).  That assumes we're doing no harm, or less harm than we
> would be tracking each page independently.
> 
> If userspace gives us a hint like "I want this range of memory on that
> node", that's a strong signal that *this* range of memory is considered
> by userspace to be a single unit.  So my opinion is that userspace is
> letting us know that we previously made a bad decision and we should
> rectify it by splitting now.

Apart from MADV_HUGEPAGE, what do you need wrt tracking THP and splitting it?