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 01851C433EF for ; Mon, 16 May 2022 22:30:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EE356B0072; Mon, 16 May 2022 18:30:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39CA06B0073; Mon, 16 May 2022 18:30:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 265ED6B0074; Mon, 16 May 2022 18:30:21 -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 13B476B0072 for ; Mon, 16 May 2022 18:30:21 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id D09AA1210CE for ; Mon, 16 May 2022 22:30:20 +0000 (UTC) X-FDA: 79473051000.07.4AA5B14 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf25.hostedemail.com (Postfix) with ESMTP id B34E2A00BC for ; Mon, 16 May 2022 22:29:57 +0000 (UTC) Received: by mail-wr1-f47.google.com with SMTP id h14so2656555wrc.6 for ; Mon, 16 May 2022 15:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=SfNwAhG3H0WFr7m8ORYPNz7dtqzeGJlfJ6gnUv4p940=; b=gj1nmb9U1n9DLHipYZgC3NBMcWDJ5bVYuNXQjOsvwVIGUIQ/CcWWoca+1jjdc5LK7s ifJDqlmUcsCETFXm7KLp0q5sdkd6xdCjJdVjbB2tTjE7DZcv5kfscr4ocsxgBFbeJf0D 4gHcQ+F+EOufpbPscNALZB6Ni/Xz/mDvn1UAS5DxK1MNfhIQtSE31jX+oLsQs2jX6m/p 0kMXKbQuuisx7dhP3sQa3Ovjr1FwNS3D5PuoCQds4MyIvlumtQjInoZSbj6fb6vGifSM z0Yky2cbkNNCgm+amQv5WA9eA/+pSCqh8EUpmM2xux0PZWSBvaw87/6l3rzC7k1ZejXK Al4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=SfNwAhG3H0WFr7m8ORYPNz7dtqzeGJlfJ6gnUv4p940=; b=8GlQI9fNnFXnJf0CBwdDmKl10O3B5LUkgDSXatVXYfDfYYy2dQcAvxpDSlQORWbEg6 jat7qvwFe/O9cRZr5iTQ9UCeK4E+K0FnBh9DBIFkTMZ1RTQIads4PTaVryIJQz9bmwuR p9/WLjNUdFL2nOVYQOczWGi0pAXs/jCPs+wxVatgw0fdSVveLNBaXgNPBKSBDMy7QQM0 d9+vjVNaZu5aPCPMfIN7v4DY5nCJecWypxIaTSNKwcEH55pU7Gs8sqKKm5vQAAAxrU91 xBgRQ7DD+Jw6u22CoUNKYiVxZfOZn+lrq3Ker/twAYEKOtWYfIOwqUCtTvP/jk+lwPQI +Pjw== X-Gm-Message-State: AOAM530T5nqTXjvBzVxa+LUoEMpkOcvhu7BXpN0EUfYXhsE6bQTlpdXI 4IpQm/o+VCohXUpyidm+JRYM18qcLXD+oTrH+K+zkA== X-Google-Smtp-Source: ABdhPJzpRSxX7Yzlv8maoFz3VbbYYVw1ANULRNMRGLf7c3HnLdTVCWaZEgvHobugUrcpBYsEP+sjS0F8e36by3XzzB8= X-Received: by 2002:adf:fb05:0:b0:20a:e113:8f3f with SMTP id c5-20020adffb05000000b0020ae1138f3fmr16135659wrr.534.1652740218347; Mon, 16 May 2022 15:30:18 -0700 (PDT) MIME-Version: 1.0 From: Yosry Ahmed Date: Mon, 16 May 2022 15:29:42 -0700 Message-ID: Subject: [RFC] Add swappiness argument to memory.reclaim To: Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Roman Gushchin Cc: 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: B34E2A00BC X-Stat-Signature: inrxt733fr57n3zcbj68tfs9k13gxtjn Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=gj1nmb9U; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-HE-Tag: 1652740197-568040 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: 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. The interface would be something like this (utilizing the nested-keyed interface we documented earlier): $ echo "200M swappiness=30" > memory.reclaim Looking forward to hearing thoughts about this before I go ahead and send a patch. [1]https://lore.kernel.org/lkml/20220331084151.2600229-1-yosryahmed@google.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yosry Ahmed Subject: [RFC] Add swappiness argument to memory.reclaim Date: Mon, 16 May 2022 15:29:42 -0700 Message-ID: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=SfNwAhG3H0WFr7m8ORYPNz7dtqzeGJlfJ6gnUv4p940=; b=gj1nmb9U1n9DLHipYZgC3NBMcWDJ5bVYuNXQjOsvwVIGUIQ/CcWWoca+1jjdc5LK7s ifJDqlmUcsCETFXm7KLp0q5sdkd6xdCjJdVjbB2tTjE7DZcv5kfscr4ocsxgBFbeJf0D 4gHcQ+F+EOufpbPscNALZB6Ni/Xz/mDvn1UAS5DxK1MNfhIQtSE31jX+oLsQs2jX6m/p 0kMXKbQuuisx7dhP3sQa3Ovjr1FwNS3D5PuoCQds4MyIvlumtQjInoZSbj6fb6vGifSM z0Yky2cbkNNCgm+amQv5WA9eA/+pSCqh8EUpmM2xux0PZWSBvaw87/6l3rzC7k1ZejXK Al4A== List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Roman Gushchin Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo , Linux-MM , Yu Zhao , Wei Xu , Greg Thelen , Chen Wandun 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. The interface would be something like this (utilizing the nested-keyed interface we documented earlier): $ echo "200M swappiness=30" > memory.reclaim Looking forward to hearing thoughts about this before I go ahead and send a patch. [1]https://lore.kernel.org/lkml/20220331084151.2600229-1-yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/