Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp511228ybm; Mon, 20 May 2019 21:43:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqx7sXUR0mphWT+iGNyEwPog3/I4OCjBHH9y9D8LeHPRYavhgCPrTBnKg73Mcdo1mnEZe9vW X-Received: by 2002:aa7:8e59:: with SMTP id d25mr2078133pfr.24.1558413794395; Mon, 20 May 2019 21:43:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558413794; cv=none; d=google.com; s=arc-20160816; b=mmUfsZeEvQBQo+f6ImfOruUU9ACykd2n8fCqCNJaqcFFJvIpzoTbe8XwIhhkLhfPq2 CWFCvMWLcZzW0sApwMl60xi5FwpLrVlbvsrUZ2sB5ADuvW8ozxnoH2BENeF92mSM73lp fG5vQwZezCeRreRdkKGDhZcXMhiwsaQChJo2mqcP0SddJOfLwIxcRLCNPDYfHTLOX0c2 yPCZ6fBmNlGicFaM/XwTyvKSmttGNWnM+VHLN5iSjHzE5RVyArxsE3gffbYvqrbiw+Wn 6+okXuSG7HWAJBGaZaDHjizKIHDvbcxLElUDry9OBEG/uymnl4neWme+EBbFUCC3OErw JH0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QQkwhZ+FrBt0iCq5K6YROwDY4dt6/xx+/myXpnuTWx4=; b=nzrOFLiAC+TBVRT/fvg9iJ8gqzV4h5GhzwSJqmlbuNkT5WVcbs0+RUu7DrW1sun0XR 8tO6dFwj7+je5pM/iWvgd4K5PkLBCf5T+fqhgD8jjILncUyZwNpTV+HKQYjC/cc9E2p+ TOqYhXv/yL7A4qcu89WRwdWlm7M08V5H44WzQdJ0RVZsa+/h6PsigFjgKim7iw960Gis 0I+0XI7tXLIAz2WtDaSxOlat2pR5GCTylRGHBMJkYzqXc4CyowRXxQKsROBHpSNMTjUY SHLGYEQjl7zQt5tmkrv2d3ydIB9n3kv6CkxjAZG1dRqrSRSHAfBVtpSy7Gn/wjRtXoqa dSEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QO5rQwSX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g14si6115443pgh.98.2019.05.20.21.42.59; Mon, 20 May 2019 21:43:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QO5rQwSX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727466AbfEUEj5 (ORCPT + 99 others); Tue, 21 May 2019 00:39:57 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:40690 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726042AbfEUEj5 (ORCPT ); Tue, 21 May 2019 00:39:57 -0400 Received: by mail-pg1-f193.google.com with SMTP id d30so7890122pgm.7 for ; Mon, 20 May 2019 21:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=QQkwhZ+FrBt0iCq5K6YROwDY4dt6/xx+/myXpnuTWx4=; b=QO5rQwSX4v25HATvAZksTfI6EjXr31E65ISg3wa7Rgi+45wh+Nc67s/QBio/bGiCxj XpXtutx7gPssH+Xd9sCjEzvAXWl+YYTuoMcSfqUB6YdCsqDiXmbCW/gEzauJ473iqGp+ +kVbmM7thyPsWxY6WFV9RGiW3WLCVx/uv3vQHpy3NPuH/7R1CrZmIljMx9pvsxRuXkbc 7SoMfs2fQkMEeDeNLJ3eNAzSQy4VDAMh4OrN9FQMY+8f8ARo/KGLQ7dX4UID1aDS3epb DbYbiaD39kGowIZ66+bRqNKIIsPg3h3p+/6PQAr9RDHCrsN+XINT4BdkIBXTqVSEWNnl OcGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=QQkwhZ+FrBt0iCq5K6YROwDY4dt6/xx+/myXpnuTWx4=; b=YHQpkg3rUWJdYbXOkw/7ElyDBuKAwvwOpyO32AjzoTb91eIsBgM2sUtFfL4ZdG7wxH /ZGUWDLhk0GWBBQC8L8FESXSuLTL4/aWqnqBibHpcsrfUFD3ri7sCJVw+KA0HDiaZuON jAPCYls8SRNPFMsnlcnUDZ7isVWGx9JW5GL/5wLkmvwO02r/AZs4qMpR8lNx/vAGCqw4 xpjKYtksHslOHtRaBwYdz3qeWRA9VSyJVDf+L7wb9jCcjKJZzoUWcDbrs3a8cBjAGuYb BPTaZrx8ScECo3/MTNhCUHVdzDOdJoWclLxQZatIVE8G6reUQnrIgO2icDenOcQgH2rr E4CA== X-Gm-Message-State: APjAAAXTM/sHzhGHGyvYhMsmP9Hsp0qQVkqgii+lqDh+EYDgcK5/YWH6 HuAhECJhuiseLQo5wWEzrbU= X-Received: by 2002:a63:c64c:: with SMTP id x12mr78971864pgg.379.1558413596600; Mon, 20 May 2019 21:39:56 -0700 (PDT) Received: from google.com ([2401:fa00:d:0:98f1:8b3d:1f37:3e8]) by smtp.gmail.com with ESMTPSA id w12sm29519966pfj.41.2019.05.20.21.39.52 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 20 May 2019 21:39:55 -0700 (PDT) Date: Tue, 21 May 2019 13:39:50 +0900 From: Minchan Kim To: Johannes Weiner Cc: Andrew Morton , LKML , linux-mm , Michal Hocko , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Daniel Colascione , Shakeel Butt , Sonny Rao , Brian Geffon Subject: Re: [RFC 0/7] introduce memory hinting API for external process Message-ID: <20190521043950.GJ10039@google.com> References: <20190520035254.57579-1-minchan@kernel.org> <20190520164605.GA11665@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190520164605.GA11665@cmpxchg.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 20, 2019 at 12:46:05PM -0400, Johannes Weiner wrote: > On Mon, May 20, 2019 at 12:52:47PM +0900, Minchan Kim wrote: > > - Approach > > > > The approach we chose was to use a new interface to allow userspace to > > proactively reclaim entire processes by leveraging platform information. > > This allowed us to bypass the inaccuracy of the kernel’s LRUs for pages > > that are known to be cold from userspace and to avoid races with lmkd > > by reclaiming apps as soon as they entered the cached state. Additionally, > > it could provide many chances for platform to use much information to > > optimize memory efficiency. > > > > IMHO we should spell it out that this patchset complements MADV_WONTNEED > > and MADV_FREE by adding non-destructive ways to gain some free memory > > space. MADV_COLD is similar to MADV_WONTNEED in a way that it hints the > > kernel that memory region is not currently needed and should be reclaimed > > immediately; MADV_COOL is similar to MADV_FREE in a way that it hints the > > kernel that memory region is not currently needed and should be reclaimed > > when memory pressure rises. > > I agree with this approach and the semantics. But these names are very > vague and extremely easy to confuse since they're so similar. > > MADV_COLD could be a good name, but for deactivating pages, not > reclaiming them - marking memory "cold" on the LRU for later reclaim. > > For the immediate reclaim one, I think there is a better option too: > In virtual memory speak, putting a page into secondary storage (or > ensuring it's already there), and then freeing its in-memory copy, is > called "paging out". And that's what this flag is supposed to do. So > how about MADV_PAGEOUT? > > With that, we'd have: > > MADV_FREE: Mark data invalid, free memory when needed > MADV_DONTNEED: Mark data invalid, free memory immediately > > MADV_COLD: Data is not used for a while, free memory when needed > MADV_PAGEOUT: Data is not used for a while, free memory immediately > > What do you think? There are several suggestions until now. Thanks, Folks! For deactivating: - MADV_COOL - MADV_RECLAIM_LAZY - MADV_DEACTIVATE - MADV_COLD - MADV_FREE_PRESERVE For reclaiming: - MADV_COLD - MADV_RECLAIM_NOW - MADV_RECLAIMING - MADV_PAGEOUT - MADV_DONTNEED_PRESERVE It seems everybody doesn't like MADV_COLD so want to go with other. For consisteny of view with other existing hints of madvise, -preserve postfix suits well. However, originally, I don't like the naming FREE vs DONTNEED from the beginning. They were easily confused. I prefer PAGEOUT to RECLAIM since it's more likely to be nuance to represent reclaim with memory pressure and is supposed to paged-in if someone need it later. So, it imply PRESERVE. If there is not strong against it, I want to go with MADV_COLD and MADV_PAGEOUT. Other opinion?