From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14AD2C46470 for ; Fri, 31 May 2019 08:47:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E26A52479C for ; Fri, 31 May 2019 08:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559292477; bh=D+yLBKqr975QJsixWB4wyv6wZEEE6jqGqlntHmrGCi8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=0IqT3aE4+ab+W5Tz5GHKdyq44xYeMQ87bHr9ugdul4boLvSGVKEYDmw/gncX3EVk2 9Ss5TaU1oQZSttjYGCUSMK5dNvk9hX4997HSgM1aqAIBrDiDe1Ww3P9bXrj4eLgMHa nK9WIaD5yJ+FCpgXt7yV76h8VO9MiiQEovqKszDk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727080AbfEaIrz (ORCPT ); Fri, 31 May 2019 04:47:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:55688 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727058AbfEaIrz (ORCPT ); Fri, 31 May 2019 04:47:55 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CF1F3AF55; Fri, 31 May 2019 08:47:53 +0000 (UTC) Date: Fri, 31 May 2019 10:47:52 +0200 From: Michal Hocko To: Minchan Kim Cc: Andrew Morton , linux-mm , LKML , linux-api@vger.kernel.org, Johannes Weiner , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Daniel Colascione , Shakeel Butt , Sonny Rao , Brian Geffon , jannh@google.com, oleg@redhat.com, christian@brauner.io, oleksandr@redhat.com, hdanton@sina.com Subject: Re: [RFCv2 1/6] mm: introduce MADV_COLD Message-ID: <20190531084752.GI6896@dhcp22.suse.cz> References: <20190531064313.193437-1-minchan@kernel.org> <20190531064313.193437-2-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190531064313.193437-2-minchan@kernel.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 Archived-At: List-Archive: List-Post: On Fri 31-05-19 15:43:08, Minchan Kim wrote: > When a process expects no accesses to a certain memory range, it could > give a hint to 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_COLD hint to madvise(2) syscall. > MADV_COLD 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. > > Internally, it works via deactivating pages from active list to inactive's > head if the page is private because inactive list could be full of > used-once pages which are first candidate for the reclaiming and that's a > reason why MADV_FREE move pages to head of inactive LRU list. Therefore, > if the memory pressure happens, they will be reclaimed earlier than other > active pages unless there is no access until the time. [I am intentionally not looking at the implementation because below points should be clear from the changelog - sorry about nagging ;)] What kind of pages can be deactivated? Anonymous/File backed. Private/shared? If shared, are there any restrictions? Are there any restrictions on mappings? E.g. what would be an effect of this operation on hugetlbfs mapping? Also you are talking about inactive LRU but what kind of LRU is that? Is it the anonymous LRU? If yes, don't we have the same problem as with the early MADV_FREE implementation when enough page cache causes that deactivated anonymous memory doesn't get reclaimed anytime soon. Or worse never when there is no swap available? -- Michal Hocko SUSE Labs