From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suren Baghdasaryan Subject: Re: [RFC 1/7] mm: introduce MADV_COOL Date: Mon, 20 May 2019 08:08:45 -0700 Message-ID: References: <20190520035254.57579-1-minchan@kernel.org> <20190520035254.57579-2-minchan@kernel.org> <20190520081621.GV6836@dhcp22.suse.cz> <20190520081943.GW6836@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190520081943.GW6836@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org To: Michal Hocko Cc: Minchan Kim , Andrew Morton , LKML , linux-mm , Johannes Weiner , Tim Murray , Joel Fernandes , Daniel Colascione , Shakeel Butt , Sonny Rao , Brian Geffon , linux-api@vger.kernel.org List-Id: linux-api@vger.kernel.org On Mon, May 20, 2019 at 1:19 AM Michal Hocko wrote: > > On Mon 20-05-19 10:16:21, Michal Hocko wrote: > > [CC linux-api] > > > > On Mon 20-05-19 12:52:48, Minchan Kim wrote: > > > When a process expects no accesses to a certain memory range > > > it could hint kernel that the pages can be reclaimed > > > when memory pressure happens but data should be preserved > > > for future use. This could reduce workingset eviction so it > > > ends up increasing performance. > > > > > > This patch introduces the new MADV_COOL hint to madvise(2) > > > syscall. MADV_COOL can be used by a process to mark a memory range > > > as not expected to be used in the near future. The hint can help > > > kernel in deciding which pages to evict early during memory > > > pressure. > > > > I do not want to start naming fight but MADV_COOL sounds a bit > > misleading. Everybody thinks his pages are cool ;). Probably MADV_COLD > > or MADV_DONTNEED_PRESERVE. > > OK, I can see that you have used MADV_COLD for a different mode. > So this one is effectively a non destructive MADV_FREE alternative > so MADV_FREE_PRESERVE would sound like a good fit. Your MADV_COLD > in other patch would then be MADV_DONTNEED_PRESERVE. Right? > I agree that naming them this way would be more in-line with the existing API. Another good option IMO could be MADV_RECLAIM_NOW / MADV_RECLAIM_LAZY which might explain a bit better what they do but Michal's proposal is more consistent with the current API. > -- > Michal Hocko > SUSE Labs