On Wed, Jan 27, 2016 at 04:28:35PM +0100, Michal Hocko wrote: > On Wed 27-01-16 10:24:25, Naoya Horiguchi wrote: > > Some new MADV_* advices are not documented in sys_madvise() comment. > > So let's update it. > > > > Signed-off-by: Naoya Horiguchi <[email protected]> > > Other than few suggestions below > Acked-by: Michal Hocko <[email protected]> > > > --- > > mm/madvise.c | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git v4.4-mmotm-2016-01-20-16-10/mm/madvise.c > > v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c > > index 6a77114..c897b15 100644 > > --- v4.4-mmotm-2016-01-20-16-10/mm/madvise.c > > +++ v4.4-mmotm-2016-01-20-16-10_patched/mm/madvise.c > > @@ -639,14 +639,26 @@ madvise_behavior_valid(int behavior) > > * some pages ahead. > > * MADV_DONTNEED - the application is finished with the given range, > > * so the kernel can free resources associated with it. > > + * MADV_FREE - the application marks pages in the given range as lasyfree, > > s@lasyfree@lazy free@ > > > + * where actual purges are postponed until memory pressure happens. > > * MADV_REMOVE - the application wants to free up the given range of > > * pages and associated backing store. > > * MADV_DONTFORK - omit this area from child's address space when forking: > > * typically, to avoid COWing pages pinned by get_user_pages(). > > * MADV_DOFORK - cancel MADV_DONTFORK: no longer omit this area when > > forking. > > + * MADV_HWPOISON - trigger memory error handler as if the given memory > > range > > + * were corrupted by unrecoverable hardware memory failure. > > + * MADV_SOFT_OFFLINE - try to soft-offline the given range of memory. > > * MADV_MERGEABLE - the application recommends that KSM try to merge > > pages in > > * this area with pages of identical content from other such areas. > > * MADV_UNMERGEABLE- cancel MADV_MERGEABLE: no longer merge pages with > > others. > > + * MADV_HUGEPAGE - the application wants to allocate transparent > > hugepages to > > + * load the content of the given memory range. > > I guess that a slightly different wording would be better: > > application wants to back the given range by transparent huge pages in > the future. Existing pages might be coalesced and new pages might be > allocated as THP. > > > + * MADV_NOHUGEPAGE - cancel MADV_HUGEPAGE: no longer allocate transparent > > + * hugepages. > > Mark the given range as not worth being backed by transparent huge pages > so neither existing pages will be coalesced into THP nor new pages will > be allocated as THP.
Thank you for the elaboration. I'm fine for all these change. - Naoya
