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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E387AC433EF for ; Tue, 17 May 2022 18:07:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DC9B8D0001; Tue, 17 May 2022 14:07:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68B616B0074; Tue, 17 May 2022 14:07:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 553338D0001; Tue, 17 May 2022 14:07:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 46AB86B0073 for ; Tue, 17 May 2022 14:07:14 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1856621AEA for ; Tue, 17 May 2022 18:07:14 +0000 (UTC) X-FDA: 79476016788.12.7185B89 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf04.hostedemail.com (Postfix) with ESMTP id D3C41400D0 for ; Tue, 17 May 2022 18:07:00 +0000 (UTC) Received: by mail-wr1-f50.google.com with SMTP id k30so13111723wrd.5 for ; Tue, 17 May 2022 11:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f5miC2kWn/l2e0BUuAIeZlYgpjUY+Gi8Grdp3KqcrK8=; b=UXqcmaywsD5AB9IxCHPt0Uzp0QohHozlmtmz6BUjExY3c7FuVDvcAcFQPalL4lBncW HtxU2aNWgnohBNpUkXNy+DMO7+l8Aegg71l0oKsr2IbYmOXivgmCvqYeFrXCGjan04ps ZvtMyokVjpdqSs/XCEBXmjvND+xdFFHhS4+8FmNzP0sffxiidGouM1ciTVqvVK8lMe4I zEcOxXsXYwHSqvRi89rmltszgIXa2B2qqfRRhcat7Zq59yG6GNoXxAFvzvqtctcP9Mmp fIJIGOBXKWXzGaWOqzbGojB9SYCA0y6yoI2nss/O5wQvCxq6wXVn5a4cAlRTGeth+PyV Bkcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f5miC2kWn/l2e0BUuAIeZlYgpjUY+Gi8Grdp3KqcrK8=; b=1feQTxJhxnbfjoLH48jRa6Kc9OSsPtMwDjvVAUh7DCwNVc/AKqo9p2KTDXvvf6lTbT A7+rq43+K4G4WGfYzSGqc0jzdTNr/fcrEPg9mHlrdLJhfepbJRVtsmli3hx1UzObWb4T fhk4tNN6r+CHXAS5quYEFIqWWaOJ5BxGUk/ZQot2KR+i86owk89mC8oEKJJfDT+wJaI8 T0Yu/+wZCn848FkQQXl2G/vGokgM8+BBVRtEcpY4p953WVOpCjaHixzNW9Y4ZsFeN39U wqGm9zju1MYl0ocSpcW+MGnMzI/RnDu+xNTrg15Yn7q4STKhMgdD+AetDvhyjzjUs7xH 6JTg== X-Gm-Message-State: AOAM531DMvh+Yv1rrGDkhOeG6dyLYMUjEqyB7fIhEAJL1kRR2TPGc3sz ETV6KnZkn9rMZW7h0iSo+pL45rQP+R74CQrK5u0j1A== X-Google-Smtp-Source: ABdhPJxgPBQ3jZTZo+4lcUoUUl3HUD7KiwclMhzdPE5ncEPURSEx6ftaxhVvrc8sFgY/RBdbkWQeiKwl97+aJV93RCg= X-Received: by 2002:a05:6000:1815:b0:20a:deee:3cf0 with SMTP id m21-20020a056000181500b0020adeee3cf0mr19322657wrh.210.1652810832119; Tue, 17 May 2022 11:07:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Tue, 17 May 2022 11:06:36 -0700 Message-ID: Subject: Re: [RFC] Add swappiness argument to memory.reclaim To: Michal Hocko Cc: Johannes Weiner , Shakeel Butt , Andrew Morton , David Rientjes , Roman Gushchin , cgroups@vger.kernel.org, Tejun Heo , Linux-MM , Yu Zhao , Wei Xu , Greg Thelen , Chen Wandun Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D3C41400D0 X-Stat-Signature: t99qxrqqt6f4uwf8jhfa1oqbrikswk77 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UXqcmayw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-HE-Tag: 1652810820-31928 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 16, 2022 at 11:56 PM Michal Hocko wrote: > > On Mon 16-05-22 15:29:42, Yosry Ahmed wrote: > > The discussions on the patch series [1] to add memory.reclaim has > > shown that it is desirable to add an argument to control the type of > > memory being reclaimed by invoked proactive reclaim using > > memory.reclaim. > > > > I am proposing adding a swappiness optional argument to the interface. > > If set, it overwrites vm.swappiness and per-memcg swappiness. This > > provides a way to enforce user policy on a stateless per-reclaim > > basis. We can make policy decisions to perform reclaim differently for > > tasks of different app classes based on their individual QoS needs. It > > also helps for use cases when particularly page cache is high and we > > want to mainly hit that without swapping out. > > Can you be more specific about the usecase please? Also how do you For example for a class of applications it may be known that reclaiming one type of pages anon/file is more profitable or will incur an overhead, based on userspace knowledge of the nature of the app. If most of what an app use for example is anon/tmpfs then it might be better to explicitly ask the kernel to reclaim anon, and to avoid reclaiming file pages in order not to hurt the file cache performance. It could also be a less aggressive alternative to /proc/sys/vm/drop_caches. > define the semantic? Behavior like vm_swappiness is rather vague because > the kernel is free to ignore (and it does indeed) this knob in many > situations. What is the expected behavior when user explicitly requests > a certain swappiness? My initial thoughts was to have the same behavior as vm_swappiness, but stateless. If a user provides a swappiness value then we use it instead of vm_swappiness. However, I am aware that the definition is vague and there are no guarantees here, the only reason I proposed swappiness vs. explicit type arguments (like the original RFC and Roman's reply) is flexibility. It looks like explicit type arguments would be more practical though. I will continue the discussion replying to Roman. > -- > Michal Hocko > SUSE Labs