Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp217845ybf; Thu, 27 Feb 2020 19:38:57 -0800 (PST) X-Google-Smtp-Source: APXvYqxtI2rFhkjKEDoYm8IOCv5AMQNOXm5kRpiHeoIhEI+S55EZXn53wkuOTcxOD2g2mzYLsL7b X-Received: by 2002:aca:5447:: with SMTP id i68mr1658492oib.31.1582861137038; Thu, 27 Feb 2020 19:38:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582861137; cv=none; d=google.com; s=arc-20160816; b=m/89/qMpBMNfSxjkMDbba1RmoJb8IdwGZLoDKmTzCuYkHwGXZhaGhAqz/X+N+8HP7y /7YpNl28clrSBS82GJXtS1vPMQMmIHXbJHo2nlpk06aE0EcdN4lCHVMHIdkDXxDifEzP 7cRC0L+EQer6QO11j6CABW07bHAlqUFIujngi2JLBXPIIsKDmRTxqs9FRuIWV7hiXSRN Jj/kSC7v4ZmAU6b7Lj/A6Ulal6dEY5P3vibn7LgiPKYmFxYzuh+CtDoAyU/LEufzbUUO HbhWmwd6DW2qZ2IfqBVaMwHxYvA9bdRhKAbje6QkXDCOoSPUoeDcsqjI+8Rr4Z/5oowy goVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=JI2r8Da0ihGHw9oHSEDobbqNIVA++evcraJkAZiK3Fo=; b=t1BuGuzQvLY9/0j9NDcY/k3VeXAz2nxuYPy4CmO8vU1klJGMYqSvh6yshEULIpTJvn DCaCe3cPJysN7en1WupvWsabi+xtEAGJVLZIUq1esdo1eeN/6zBJxrsIvVHiu7yjh63m Q8/8jO1qUV9tsvIRwMdp21VL9F2q1dP2UjyZN3SVfZBOaMZ3WWIzKGPOX1TCub9ZhQKZ Ch8cGOv+1ZvzD8tfXeGjqVaQw26wtcNhZxghkw64xlDE1kMcLOeu49N6gYsdgER+7lJ9 C/Z06XSe8A1VioC6BSKkg830qS2D4zCEv7gVc4pAk/fMAfzk2ewXidduGzj4hrMCUxqG Reyw== ARC-Authentication-Results: i=1; mx.google.com; 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k16si1057477oiw.128.2020.02.27.19.38.45; Thu, 27 Feb 2020 19:38:57 -0800 (PST) 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; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730737AbgB1Dih (ORCPT + 99 others); Thu, 27 Feb 2020 22:38:37 -0500 Received: from mga09.intel.com ([134.134.136.24]:36522 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730586AbgB1Dih (ORCPT ); Thu, 27 Feb 2020 22:38:37 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 19:38:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,493,1574150400"; d="scan'208";a="232107346" Received: from yhuang-dev.sh.intel.com ([10.239.159.23]) by orsmga008.jf.intel.com with ESMTP; 27 Feb 2020 19:38:33 -0800 From: "Huang, Ying" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , David Hildenbrand , Mel Gorman , Vlastimil Babka , Zi Yan , Michal Hocko , Peter Zijlstra , Dave Hansen , Minchan Kim , Johannes Weiner , Hugh Dickins Subject: [RFC 0/3] mm: Discard lazily freed pages when migrating Date: Fri, 28 Feb 2020 11:38:16 +0800 Message-Id: <20200228033819.3857058-1-ying.huang@intel.com> X-Mailer: git-send-email 2.25.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Huang Ying MADV_FREE is a lazy free mechanism in Linux. According to the manpage of mavise(2), the semantics of MADV_FREE is, The application no longer requires the pages in the range specified by addr and len. The kernel can thus free these pages, but the freeing could be delayed until memory pressure occurs. ... Originally, the pages freed lazily by MADV_FREE will only be freed really by page reclaiming when there is memory pressure or when unmapping the address range. In addition to that, there's another opportunity to free these pages really, when we try to migrate them. The main value to do that is to avoid to create the new memory pressure immediately if possible. Instead, even if the pages are required again, they will be allocated gradually on demand. That is, the memory will be allocated lazily when necessary. This follows the common philosophy in the Linux kernel, allocate resources lazily on demand. This patchset implement this in addition to some cleanup to migration and MADV_FREE code. Best Regards, Huang, Ying