Re: [PATCH v2] mm: incorporate zero pages into transparent huge pages

[Vlastimil Babka]

On 23.2.2015 20:43, Rik van Riel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/23/2015 02:16 PM, Andrew Morton wrote:
> > On Wed, 18 Feb 2015 19:08:12 -0500 Rik van Riel <riel@xxxxxxxxxx>
> > wrote:
> > > > If so, this might be rather undesirable behaviour in some
> > > > situations (and ditto the current behaviour for pte_none
> > > > ptes)?
> > > >
> > > > This can be tuned by adjusting khugepaged_max_ptes_none,
> > Here's a live one:
> > https://bugzilla.kernel.org/show_bug.cgi?id=93111
> >
> > Application does MADV_DONTNEED to free up a load of memory and
> > then khugepaged comes along and pages that memory back in again.
> > It seems a bit silly to do this after userspace has deliberately
> > discarded those pages!

OK that's a nice example how a more conservative default for
max_ptes_none would make sense even with the current aggressive
THP faulting.

> > Presumably MADV_NOHUGEPAGE can be used to prevent this, but it's a
> > bit of a hand-grenade.  I guess the MADV_DONTNEED manpage should be
> > updated to explain all this?

Probably, together with the tunable documentation. Seems like we
didn't add enough details to madvise manpage in the recent round :)

> That makes me wonder what a good value for khugepaged_max_ptes_none
> would be.
>
> Doubling the amount of memory a program uses seems quite unreasonable.
>
> Increasing the amount of memory a program uses by 512x seems totally
> unreasonable.
>
> Increasing the amount of memory a program uses by 20% might be
> reasonable, if that much memory is available, since that seems to
> be about how much performance improvement we have ever seen from
> THP.
>
> Andrew, Andrea, do you have any ideas on this?
>
> Is this something to just set, or should we ask Ebru to run
> a few different tests with this?

If there is a good test for this, sure.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/