From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935264AbcA1FyN (ORCPT ); Thu, 28 Jan 2016 00:54:13 -0500 Received: from TYO202.gate.nec.co.jp ([210.143.35.52]:50267 "EHLO tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934031AbcA1FyK convert rfc822-to-8bit (ORCPT ); Thu, 28 Jan 2016 00:54:10 -0500 From: Naoya Horiguchi To: Michal Hocko CC: Andrew Morton , Minchan Kim , "Kirill A. Shutemov" , "Jason Baron" , Chen Gong , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Naoya Horiguchi Subject: Re: [PATCH v1] mm/madvise: update comment on sys_madvise() Thread-Topic: [PATCH v1] mm/madvise: update comment on sys_madvise() Thread-Index: AQHRWY/aO7SOuEBNJkeEJzYMQqHnXQ== Date: Thu, 28 Jan 2016 05:50:56 +0000 Message-ID: <20160128055055.GA8747@hori1.linux.bs1.fc.nec.co.jp> References: <1453857865-13650-1-git-send-email-n-horiguchi@ah.jp.nec.com> <20160127152835.GD13956@dhcp22.suse.cz> In-Reply-To: <20160127152835.GD13956@dhcp22.suse.cz> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.12] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <3921E6AA12F5DC49B2BD906980B38557@gisp.nec.co.jp> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > Other than few suggestions below > Acked-by: Michal Hocko > > > --- > > 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