From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbdBAQho (ORCPT ); Wed, 1 Feb 2017 11:37:44 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:33035 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdBAQhl (ORCPT ); Wed, 1 Feb 2017 11:37:41 -0500 Date: Wed, 1 Feb 2017 08:37:12 -0800 From: Shaohua Li To: Johannes Weiner CC: , , , , , , , Subject: Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages Message-ID: <20170201163711.GA56014@shli-mbp.local> References: <20170131185949.GA5037@cmpxchg.org> <20170131194546.GA70126@shli-mbp.local> <20170131213810.GA12952@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170131213810.GA12952@cmpxchg.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [2620:10d:c090:180::1:ebc1] X-ClientProxiedBy: BN6PR08CA0061.namprd08.prod.outlook.com (10.172.144.23) To BN6PR15MB1635.namprd15.prod.outlook.com (10.175.131.9) X-MS-Office365-Filtering-Correlation-Id: ddf940b1-c317-46bb-6d02-08d44ac098d5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR15MB1635; X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;3:v0VUmoU6nt5FnY2S/RYX90SagfglqkRQlnFkep7erm8vw1MP0JVf7SuTwzPcsI9ZJyPzmMGXOvE3IWfybFfkxHMdrBzAHO7D+wXeefJITICNrrW9NgMSvxjhXaKA5vmMhV38jkuWzjnOXDdtrBL1qr7B2+Ujo4KN5mLAdmCKF+9BD14LuYVOed/U2+CZDX/8W/hiT1lfHoGLtexlM18nVr/HRb5xMSAfnU4kq26tjTFCJqi9x05C0Tx2eoK+8FwR8iMopT+QQpHwSOOaFaFyMw== X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;25:lLw/MWQpL5WrjchFBiYmE96v8O03Xp7tXzz1pd2jgavi4eRF2ak3b0lpGfnK8gIpUGlIS0Ti5AuHGRnQ7rYIuUeRmT+DrQeUnKvAXtfJ/6TssB6vpzzG+SBcmC2wKw3F+K4PpkgUOEcSmc6SLEZZ+3SbywuUEeYt71Qaun85DQCQ3kyojRR0WMk8x/XM/ZJeUc+ebJ1Fmkpvz4zjevd1bFjRff2aqBocA4t27ljvWQQ4u5SmdAtIcIADZeDnr1ntN0P1TlrA16A1xbtmn69HIUVMLFgdDUxJotDsZQ7Ba/FbXTvnx7X/+eBgaAsgH8BMKllBxlFTC496O8q1WQrJi8odlkULnm90zTNHKMwB/8n6nKIHknVV9nXFBVu+dk3E3UcMWFuQWFkV+tJCZjiNF7HBQ14VhCEecO1MQfeG/ckQRSe6g4KZ+HiGNVVlUbWMzMbZptccpRvjeLa11fAZzNUyL6KGS43g76B3qwQeBzRaA9Bf0NHQp7UpaQaO0K/G2vuFrm3Y7OQDrV6lUX+K9zc4mXKPPgihPLiwDhtXkGJclbmF+2N9cEbMtFjvyjYoaoyoOPnwVKe9oE1skfPVigrckGk3lVe9tkcrZhg5GPODuFGK7EhDz7hphVMnA5XidiZRJYZ/AZ36SIFLnTz6w9lZiiOVVcC+IKKU7UXAzxd6HCwNuBqZpN4Gyzd5/ZjD X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;31:CWiDLSzV5597ypYIVkBYpVLEHcEVVOUUjH3cOZTyND8CKeofy5tiBV4e2Y3TdJbcPAh+dnt3PjEEcJrqYyQDGDJ6OOMBsph9DLyXbfBXGBKVCPhwtgd3jdjdFov8v2nqjNF5FaSOeN7GcpDpAJFtL7Dx41x51pvygcpHDA6wcBy9KCrIvwBapNPQwcer9i46Rjp6qckx8dEKh6PbdluXadF0cWnW9QOfuPd6r+fr++tS/GqSlWqiPknbZhaMOoUNvO+SaKgHM4S8I4M8zTaraw==;20:MXLvjqB2y1TrWMPry+rhw5W7Qf2uk78/BzJmt5tF3V9TzEgmsFMwxSLkRaKSyWn0ft22auOLS3KyWvSljeK5+rtOVPubyVaxXtVsOIDkFhQ3OczOhN7IVHKIkUftAbMPtdoZsB5786Lq9Q6v/SKORNNrZa56J+S1IuCn8ZnaWDn11+CMyXhE/AMozbRNZnYiavGgrFP5Xi8SLTLBKYfe+IkmWs3MwM4e5X48zgTeg1Ak82/2SyuGxKBViiq/1QPfVEnInDu+wfabKcYxJxpGzjgayvc4DI7y4D7SecH4CuMe/3HmKKLKzNVWrI+xZzZqJoHjKxbBwo3mEvT+JipLzVn/sjlm8zUF6zherh1oE4UqSShRn8rJwvuwWXnwTIK4WWOnE9YupcgPmtj2gjdvJuQ62GVgJ5IAdPtjbJe1QV9i38dnZcRBcMYtLNnaD+t4CmjrWK7F+a7mri+uMdTokC879BDMDZ0fXFK5AendJDNrsLQHIQui+ETKUnB1Qelg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(20161123562025)(6072148);SRVR:BN6PR15MB1635;BCL:0;PCL:0;RULEID:;SRVR:BN6PR15MB1635; X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;4:u3goLahwtCv5/Y4vpPH1oNCOkwVCPkAufcMgo15/T1jmOQMrj2WqevE89PwEGvzJ6VJAyl08DyEzomM7UA4Q7qHZNW7Deg0y4FWILnTtdAT9Lf4mzD0lYxcOzJY5fFyYTkKANoLOg6cxP8CEdsqoSTikNP6sdl8MpgmnuesyAW6GUbgzWI3F6GgGk1GEtUqVKtubzkOqu5AcVSbZfjLUjLO/LQfVBng8gmhf6MtS60GcRqDsdMeafadG35lo4d8VDp9QxsYwawOyCNE6Us2AAseK6955bYh+XM6UUY88akRCNopkc5IvWFRp0TFgfo94kmbx7zwmEXHBIsyTNt2rNpel2dxuYvUmqJyAMPMMRM7Hk3uzM1ZbmC7nCaILtr6ci9ciUTQEeqqid42r+VnfyRqCHoBjdMuyK9nkHnW89w0eL8tm/hV38irLZ7hSCtP3/I4btj/eAVbiyAQMpxloKzwOfEq+J0CuN87BpP6KI/AgYd38C70cHhgamIEbxIccKvBNbP5uvbjgQ+xjv4+bbzBpD+H4SlORNl1WosX+SQheHJYuNqx0CWzgXOv4BKmfG1zHQ4///0K30bONYSPAx+vVpkx2tpu6c6AHdyv5wDQ= X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(39830400002)(39410400002)(39450400003)(24454002)(189002)(199003)(31014005)(6116002)(54906002)(55016002)(5660300001)(9686003)(229853002)(93886004)(97736004)(42186005)(2906002)(1076002)(105586002)(38730400001)(23726003)(50466002)(68736007)(106356001)(305945005)(7736002)(189998001)(110136003)(86362001)(6506006)(2950100002)(81166006)(92566002)(46406003)(6916009)(8676002)(101416001)(81156014)(6666003)(4326007)(53936002)(4001350100001)(83506001)(25786008)(76176999)(50986999)(54356999)(47776003)(97756001)(33656002)(98436002)(18370500001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN6PR15MB1635;H:shli-mbp.local;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN6PR15MB1635;23:UDV7FIXBds88Zo+GlZjTM4NmkavBHO5SsxFS6BGGr?= =?us-ascii?Q?TRJVcqkdDkJmY7/lFiq5tk87CaFdjNRy30QjjzC+ldjITVBXKpASpmuwdaj8?= =?us-ascii?Q?L8S/+e/DkrQ/ae3s/nO/AWZMB56dGYHNbO20YEd1jZyFaUbjP0pSNRG98GbZ?= =?us-ascii?Q?fdeCHBYpC1tpW4SJBiupfNI7N6m9Vu4nzECYdKcgSoNagxU03M4dnhiK/Usj?= =?us-ascii?Q?NoPRpXx3hjH6z4UvoO0QtatuBx1khwKAeeXJKWDMtVD373zDZCwqTcQ2zkKG?= =?us-ascii?Q?AIYIxDVISHPan9/dX+aLCYBZJznqpKZh+PjvsYh8ONsvpm8KnR+E2L+Zi9mE?= =?us-ascii?Q?5cByW/8G9ozLGURuuzUvUCAPj+kdGsISuHpd0SPdmaPEWVtiE7Iq9eudSr2g?= =?us-ascii?Q?4wZBD59MoMH6OL7fhkETk8BFS6uvpy+uxFy92gjYOcK83BRJNyluRPe35d6G?= =?us-ascii?Q?qvgALDKOJd0iz8NmmzvE5V4KrOaE8awD8C9pDTWwSOelb7sZ4yFCDCD0sR3N?= =?us-ascii?Q?+VtksOPRFKVVK3yzHPQrLVgfjKXlDTX3LUN7oSi9tw3WvyQUCerOWMzoq9S8?= =?us-ascii?Q?5JpjJaGr04ICWvhXFuhMAKgAtqAo25grviJEleX64hlrymc3tHnfyRTPlrxJ?= =?us-ascii?Q?Qj70UAu3BF6SMenD54dtd5++/kv7rxBqNnJXg34L2oPab6yzw8hmU8Vfowxj?= =?us-ascii?Q?IcbCxH+2s4LqTQapTvmFlxkfjPxU3gV9oa56zBz+qQpqA+TjcIQA++aUcEIo?= =?us-ascii?Q?uNIgS+Zml1MJUWouRI7s/tWERf4FzDsWzaB3M7Uicj83DDQsHQRbprIUgU1V?= =?us-ascii?Q?/kLTmFR7xm0/tr9Z5NuspdplbxMct80Hv0DlJyQxINkM2ZfEdarYQwXuqQMO?= =?us-ascii?Q?Y9/83euUxssDMejbzr+dQYx6WjhpcKGem1W05zDc4KdF+yrYtcA3kyM9tAf0?= =?us-ascii?Q?oJZLo5UhRE6ItZav60IJAkWizNIZCouH4wYAEjNKvsrV1WKgVWnm7uBNIkgJ?= =?us-ascii?Q?73f02mkso4si01GjR3sV3sms8LflYSeJVsEA7wqwmUa18S7CoWgZrG+PIZ7m?= =?us-ascii?Q?O/9ep2o3BLdXf+pFu+xEqz93ua+lYUyVpRIco52gvuWy2VsqJJbJjoKsmAod?= =?us-ascii?Q?2D/KkwgVsEvCD7er/bfOFngwUljsBnHuuVVSdYtfnrLmbP46oXcDjLm2cv5b?= =?us-ascii?Q?2XJA8A+bVVBJIoJzr6azSCYNFG5GL2cXwON8HjAiK5JC6Qs4u4NUxrBWS9us?= =?us-ascii?Q?acYGtAasqyTct4bhdColD/Xo1SWhQp6fwdDE+W62fjMX222gexkhjU2GTlA1?= =?us-ascii?Q?MLJ2QLFUE4UQDIdvGewxXhrXcYYtc57deDU6pq9L2EE?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;6:Qps3lU6vArTSVQpcSIDvLgWjXh2IBZColyEu+MoOOHtsHRg+ggS1qMjpJRYGnIXICc0/Na7RWjpSIX8LavVh/JZseTyk4zgMI8JWpxnfnmsgmk2vDbEUrPo7cAHj+VdhqOfba5m6/it2r4wQHXBArXBVBMKhKuGTs4buU5ao45vK4a+ZLu8s4082jx0DBIJoEx5Ksv8CLfmsynlpGGanO1Ekh3Z7YZt64svqyPzGJ2B/vzZuwALxsaHnGtSi+fvvqQUXJe098gTQ1kfkBGVdL6DT4zAALdHkehqTH8Sp7Hrg8SV5aUQN8kVj0NQtDnVi+dvp7yhnI+d1OBBwfkHPJPsaIgcMScrilxSMFGcF4E9wX06bFPDTv9W/mHVswf+dd4+UIL/Hr6xY2BMK8RcfEX+/Yn5FfC1KhW+NvaSOFcA=;5:01CZu5hrEpn91pCyYVj/bCZaQyYsL47PtYfoi5sQUm0XNn9oa0I+STfi+w5f1xPWjXxIJUrL8ArjzVtZBngNd0zn/gdklHXjN9zYrDJpitLD3eXZg7Bg/axRAzvjMaAj3ZrkFtoGp2+wyZ1uV+l4AQ==;24:2ZezyU+S7HFEvNpJu2wE5RbVUx0yMW1ve9lUDiARCqIN/kmB3WZNxoEhnThdZU8ezOaeCdgphd/sNDG/SdUH59qwfzFGd3zOPnOqkMQV7Zw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN6PR15MB1635;7:O5dej0VIWjOiJLnuxVOBm8PHCE9m49qT8lBqLR37MCro7xd+lvR+CuAA95iTiDhWB1vGPuhHjivUDgjUbfio0YPsu5umDuYQhKLuKVp6tZ2ORHY76ii045T2Ad7lDPRn463CWdsOgZ0XzYq4hemWon28oAEZyLX98B/nrSP8sP9Kv0KVgq6EuFagSrwmefYtOkDYlC/OC1KA+XE/IzN/mgjlKtBxhM1wnMSQJylguCM4nTlzHB3yXTxw3OSNXAlQNv2l6Aj0uKyj/ERtXXDLGAkgwMDErgTh39dQtMDcP7mGE+lNKBrvmipiAmGL1moYD/BDA/Ea99NgSqu5J1Agd1KMLQih+xuCM/Ubt0eMc411qNIzRmJwQZ0yWwzRdoWXUEO9Ilw+AjlgMiitMPVCTiJcNUJ3jUuZAwekuxdd8sJmskESDuJA9zW7LKo/XB0wsp2S96ePUZQj4EDWEAPVA9iSs5NtuH7TEzETMWg5qDv31GXkVK71eanViOherweoYl0fKac/2jnVA0LebfbhR1cBizc304XLGHTG/8kuNVAZqlPf1Mx018XxAJrKUxBb;20:pv6cDhWm8Pxc/75KtdmI0hDssqvEREORn889vqV1dNBsyvJE4I19WagLJudEDpdXFlrsSu3KODS3iiI/SCJ0Kyy3vyHA+byObcK3Gv7yAmH9+e+yBYDe9YEEclrx6E/EeP+mjfxvKJmCymvw7eyUh6jqFOlhnIKPI+AJG7ax1tk= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2017 16:37:21.1592 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1635 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-01_08:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote: > On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote: > > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote: > > > Hi Shaohua, > > > > > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote: > > > > We are trying to use MADV_FREE in jemalloc. Several issues are found. Without > > > > solving the issues, jemalloc can't use the MADV_FREE feature. > > > > - Doesn't support system without swap enabled. Because if swap is off, we can't > > > > or can't efficiently age anonymous pages. And since MADV_FREE pages are mixed > > > > with other anonymous pages, we can't reclaim MADV_FREE pages. In current > > > > implementation, MADV_FREE will fallback to MADV_DONTNEED without swap enabled. > > > > But in our environment, a lot of machines don't enable swap. This will prevent > > > > our setup using MADV_FREE. > > > > - Increases memory pressure. page reclaim bias file pages reclaim against > > > > anonymous pages. This doesn't make sense for MADV_FREE pages, because those > > > > pages could be freed easily and refilled with very slight penality. Even page > > > > reclaim doesn't bias file pages, there is still an issue, because MADV_FREE > > > > pages and other anonymous pages are mixed together. To reclaim a MADV_FREE > > > > page, we probably must scan a lot of other anonymous pages, which is > > > > inefficient. In our test, we usually see oom with MADV_FREE enabled and nothing > > > > without it. > > > > > > Fully agreed, the anon LRU is a bad place for these pages. > > > > > > > For the first two issues, introducing a new LRU list for MADV_FREE pages could > > > > solve the issues. We can directly reclaim MADV_FREE pages without writting them > > > > out to swap, so the first issue could be fixed. If only MADV_FREE pages are in > > > > the new list, page reclaim can easily reclaim such pages without interference > > > > of file or anonymous pages. The memory pressure issue will disappear. > > > > > > Do we actually need a new page flag and a special LRU for them? These > > > pages are basically like clean cache pages at that point. What do you > > > think about clearing their PG_swapbacked flag on MADV_FREE and moving > > > them to the inactive file list? The way isolate+putback works should > > > not even need much modification, something like clear_page_mlock(). > > > > > > When the reclaim scanner finds anon && dirty && !swapbacked, it can > > > again set PG_swapbacked and goto keep_locked to move the page back > > > into the anon LRU to get reclaimed according to swapping rules. > > > > Interesting idea! Not sure though, the MADV_FREE pages are actually anonymous > > pages, this will introduce confusion. On the other hand, if the MADV_FREE pages > > are mixed with inactive file pages, page reclaim need to reclaim a lot of file > > pages first before reclaim the MADV_FREE pages. This doesn't look good. The > > point of a separate LRU is to avoid scan other anon/file pages. > > The LRU code and the rest of VM already use independent page type > distinctions. That's because shmem pages are !PageAnon - they have a > page->mapping that points to a real address space, not an anon_vma - > but they are swapbacked and thus go through the anon LRU. This would > just do the reverse: put PageAnon pages on the file LRU when they > don't contain valid data and are thus not swapbacked. > > As far as mixing with inactive file pages goes, it'd be possible to > link the MADV_FREE pages to the tail of the inactive list, rather than > the head. That said, I'm not sure reclaiming use-once filesystem cache > before MADV_FREE is such a bad policy. MADV_FREE retains the vmas for > the sole purpose of reusing them in the (near) future. That is > actually a stronger reuse signal than we have for use-once file pages. > If somebody does continuous writes to a logfile or a one-off search > through one or more files, we should actually reclaim that cache > before we go after MADV_FREE pages that are temporarily invalidated. Thanks, I'll try this idea. Thanks, Shaohua From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 19A806B0038 for ; Wed, 1 Feb 2017 11:37:36 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id 14so493645828pgg.4 for ; Wed, 01 Feb 2017 08:37:36 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com. [67.231.153.30]) by mx.google.com with ESMTPS id s5si19606109plj.103.2017.02.01.08.37.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 08:37:35 -0800 (PST) Date: Wed, 1 Feb 2017 08:37:12 -0800 From: Shaohua Li Subject: Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages Message-ID: <20170201163711.GA56014@shli-mbp.local> References: <20170131185949.GA5037@cmpxchg.org> <20170131194546.GA70126@shli-mbp.local> <20170131213810.GA12952@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170131213810.GA12952@cmpxchg.org> Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kernel-team@fb.com, mhocko@suse.com, minchan@kernel.org, hughd@google.com, riel@redhat.com, mgorman@techsingularity.net On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote: > On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote: > > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote: > > > Hi Shaohua, > > > > > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote: > > > > We are trying to use MADV_FREE in jemalloc. Several issues are found. Without > > > > solving the issues, jemalloc can't use the MADV_FREE feature. > > > > - Doesn't support system without swap enabled. Because if swap is off, we can't > > > > or can't efficiently age anonymous pages. And since MADV_FREE pages are mixed > > > > with other anonymous pages, we can't reclaim MADV_FREE pages. In current > > > > implementation, MADV_FREE will fallback to MADV_DONTNEED without swap enabled. > > > > But in our environment, a lot of machines don't enable swap. This will prevent > > > > our setup using MADV_FREE. > > > > - Increases memory pressure. page reclaim bias file pages reclaim against > > > > anonymous pages. This doesn't make sense for MADV_FREE pages, because those > > > > pages could be freed easily and refilled with very slight penality. Even page > > > > reclaim doesn't bias file pages, there is still an issue, because MADV_FREE > > > > pages and other anonymous pages are mixed together. To reclaim a MADV_FREE > > > > page, we probably must scan a lot of other anonymous pages, which is > > > > inefficient. In our test, we usually see oom with MADV_FREE enabled and nothing > > > > without it. > > > > > > Fully agreed, the anon LRU is a bad place for these pages. > > > > > > > For the first two issues, introducing a new LRU list for MADV_FREE pages could > > > > solve the issues. We can directly reclaim MADV_FREE pages without writting them > > > > out to swap, so the first issue could be fixed. If only MADV_FREE pages are in > > > > the new list, page reclaim can easily reclaim such pages without interference > > > > of file or anonymous pages. The memory pressure issue will disappear. > > > > > > Do we actually need a new page flag and a special LRU for them? These > > > pages are basically like clean cache pages at that point. What do you > > > think about clearing their PG_swapbacked flag on MADV_FREE and moving > > > them to the inactive file list? The way isolate+putback works should > > > not even need much modification, something like clear_page_mlock(). > > > > > > When the reclaim scanner finds anon && dirty && !swapbacked, it can > > > again set PG_swapbacked and goto keep_locked to move the page back > > > into the anon LRU to get reclaimed according to swapping rules. > > > > Interesting idea! Not sure though, the MADV_FREE pages are actually anonymous > > pages, this will introduce confusion. On the other hand, if the MADV_FREE pages > > are mixed with inactive file pages, page reclaim need to reclaim a lot of file > > pages first before reclaim the MADV_FREE pages. This doesn't look good. The > > point of a separate LRU is to avoid scan other anon/file pages. > > The LRU code and the rest of VM already use independent page type > distinctions. That's because shmem pages are !PageAnon - they have a > page->mapping that points to a real address space, not an anon_vma - > but they are swapbacked and thus go through the anon LRU. This would > just do the reverse: put PageAnon pages on the file LRU when they > don't contain valid data and are thus not swapbacked. > > As far as mixing with inactive file pages goes, it'd be possible to > link the MADV_FREE pages to the tail of the inactive list, rather than > the head. That said, I'm not sure reclaiming use-once filesystem cache > before MADV_FREE is such a bad policy. MADV_FREE retains the vmas for > the sole purpose of reusing them in the (near) future. That is > actually a stronger reuse signal than we have for use-once file pages. > If somebody does continuous writes to a logfile or a one-off search > through one or more files, we should actually reclaim that cache > before we go after MADV_FREE pages that are temporarily invalidated. Thanks, I'll try this idea. Thanks, Shaohua -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org