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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 BD0DFC2BA80 for ; Tue, 7 Apr 2020 00:22:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 559682072A for ; Tue, 7 Apr 2020 00:22:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NKrU9yO+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 559682072A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AFB658E0005; Mon, 6 Apr 2020 20:22:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAAC48E0001; Mon, 6 Apr 2020 20:22:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99A888E0005; Mon, 6 Apr 2020 20:22:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 7E8C98E0001 for ; Mon, 6 Apr 2020 20:22:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 25E1B8018F20 for ; Tue, 7 Apr 2020 00:22:42 +0000 (UTC) X-FDA: 76679158164.22.deer48_8bf96a3e95647 X-HE-Tag: deer48_8bf96a3e95647 X-Filterd-Recvd-Size: 6336 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 00:22:41 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id i7so1831349edq.3 for ; Mon, 06 Apr 2020 17:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5USL9XxCiBrVUdZKeVK74BRqC2K8QZLDtTA+0ej1Qnw=; b=NKrU9yO+G2yn4uJkV72gp6H8+NTVUvCmVbyJpNsEillz3U9Ndq6nBe43anGRtUvCqS KyBH48IxgaVqs98yYgMskXZwEdsye/zYua+p91OFh/H87X1BWl4YePH5y909VzWm/WmS KwJpfc7LLkhLoMfzS414h7JDQSSraS7gUPOmXTej5+tWtPJ3DuiyX3hrqzU39M0FJ/DV nyTv1oq7unlhOLFrbUN588eNPppzNhiO/SQSdTyalT/rvZn/dwbJc6MfcwOGulLT0nnW CF/3ltvMFJRrOGFtxn6gkfFAizYBVFwqCY9rvduFLJ2qBOK0XES6+m3fmLJiBnNXSOfQ em8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5USL9XxCiBrVUdZKeVK74BRqC2K8QZLDtTA+0ej1Qnw=; b=kAXrMIW8VO1dW3Agy6CwptR/nsVajyjhE2F7+dvyWG9WVcOSHNPQRJ2rs51kCaTQxq ccvGJxpZyjzdghaMd9nD9GdagttjypgCgq7u83moDZTI/yQQNEENgfAmLIBdhqA9jZZL TEb1a+3HEGgRm/q1DmuGS6rlNibIC6FkXtmWTo2Sjm2YOaIIluDReuAnHs8eAP1EUGol PMTvpcP+jX95WI5PR7P7/Q7OdtIW2e81leY1vGkrH56lTwOyQiDRkSTmGNepusc1ih8P Krpoa/r2haBjSwPuMBwDrDYwKZDc+KhE9oJRcym5hv4MtTMNkafmGw8m5R8tmwQRth0H sadw== X-Gm-Message-State: AGi0PuYhVMj0yc0sxFbCNihEb4KqtBrfYHPqQypgMYd1hlnosLdRnHe6 tVEA8GmXET3Ej1XTplfjDO7AzDOpsAXMrwDIwaw= X-Google-Smtp-Source: APiQypLJE6qwQ1ILlj8KqGCVmefoeqjeFzDja3cy9IT0+CyDOa0O18rWcYcX3aFneP6PJRqlMKemCARlBN/OETAtgMk= X-Received: by 2002:aa7:d9cb:: with SMTP id v11mr20903338eds.206.1586218960493; Mon, 06 Apr 2020 17:22:40 -0700 (PDT) MIME-Version: 1.0 References: <1585892447-32059-1-git-send-email-iamjoonsoo.kim@lge.com> <1585892447-32059-6-git-send-email-iamjoonsoo.kim@lge.com> In-Reply-To: From: Yang Shi Date: Mon, 6 Apr 2020 17:22:28 -0700 Message-ID: Subject: Re: [PATCH v5 05/10] mm/swap: charge the page when adding to the swap cache To: Joonsoo Kim Cc: Andrew Morton , Linux MM , Linux Kernel Mailing List , Johannes Weiner , Michal Hocko , Hugh Dickins , Minchan Kim , Vlastimil Babka , Mel Gorman , kernel-team@lge.com, Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Sun, Apr 5, 2020 at 6:03 PM Joonsoo Kim wrote: > > 2020=EB=85=84 4=EC=9B=94 4=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 3:29, = Yang Shi =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > On Thu, Apr 2, 2020 at 10:41 PM wrote: > > > > > > From: Joonsoo Kim > > > > > > Currently, some swapped-in pages are not charged to the memcg until > > > actual access to the page happens. I checked the code and found that > > > it could cause a problem. In this implementation, even if the memcg > > > is enabled, one can consume a lot of memory in the system by exploiti= ng > > > this hole. For example, one can make all the pages swapped out and > > > then call madvise_willneed() to load the all swapped-out pages withou= t > > > pressing the memcg. Although actual access requires charging, it's re= ally > > > big benefit to load the swapped-out pages to the memory without press= ing > > > the memcg. > > > > > > And, for workingset detection which is implemented on the following p= atch, > > > a memcg should be committed before the workingset detection is execut= ed. > > > For this purpose, the best solution, I think, is charging the page wh= en > > > adding to the swap cache. Charging there is not that hard. Caller of > > > adding the page to the swap cache has enough information about the ch= arged > > > memcg. So, what we need to do is just passing this information to > > > the right place. > > > > > > With this patch, specific memcg could be pressured more since readahe= ad > > > pages are also charged to it now. This would result in performance > > > degradation to that user but it would be fair since that readahead is= for > > > that user. > > > > If I read the code correctly, the readahead pages may be *not* charged > > to it at all but other memcgs since mem_cgroup_try_charge() would > > retrieve the target memcg id from the swap entry then charge to it > > (generally it is the memcg from who the page is swapped out). So, it > > may open a backdoor to let one memcg stress other memcgs? > > It looks like you talk about the call path on CONFIG_MEMCG_SWAP. > > The owner (task) for a anonymous page cannot be changed. It means that > the previous owner written on the swap entry will be the next user. So, > I think that using the target memcg id from the swap entry for readahead = pages > is valid way. > > As you concerned, if someone can control swap-readahead to readahead > other's swap entry, one memcg could stress other memcg by using the fact = above. > However, as far as I know, there is no explicit way to readahead other's = swap > entry so no problem. Swap cluster readahead would readahead in pages on consecutive swap entries which may belong to different memcgs, however I just figured out patch #8 ("mm/swap: do not readahead if the previous owner of the swap entry isn't me") would prevent from reading ahead pages belonging to other memcgs. This would kill the potential problem. > Thanks.