Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1828229pxb; Fri, 5 Mar 2021 00:10:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfGrSXTm4Wli69EoYoaVJyJANNl8wQQjPs7ss1wz1nyH8OzUEKJuH4BqnDrFN7KeGBtm3E X-Received: by 2002:a17:906:b286:: with SMTP id q6mr1262401ejz.422.1614931823878; Fri, 05 Mar 2021 00:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614931823; cv=none; d=google.com; s=arc-20160816; b=YjwYCCR4TRIw1N7/IqjvBizySp2q2TCmNJtX8uqI6fXXl0QUROE+AAi7D5hECYw6/U rKX6z60mQ3phNqhybc1NsTJ4vNy8hUhl1f0Cs4IAcY7Zh3A3h8y/aUuASi9rVh7swvpn ajD+xdzp030bIK8Ge/38EWhARcim/G3KA9gum09Hv9qU8sfryvVv+mF5wabCqfiihK0i qgGFjOMm/py2cKQQyvBwbYRdPjkdUhToXTekERTtFo5xMdDVP6w7iRjyDZMkkir19OSs 115JwOTWlccSZK9J4T93aC3kkYSrsfONjbQfSgxzAYQRpE5dGEWPJpnoy3g0zV3OKd/p 2SMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=6Ntm9TYj9xnK5FJwNfSHccWZk0cH/kRpY9uFJXEGdp4=; b=TloEwg4Lt50kBaGQKR8UZp7s8x4i+cHQ9VNXHvaxpfz/QktAjyQqd/yzSts+xVcZj+ 7hA/66NT+Xb3UFabOlgNn3Gij5KeiuiUP8THEMTis+G+oHYJLkrgB3Fibqqoel19bnZT /r8sV06JUVQDxlIIu1KQtHV2YhZ9aufVPPpu8d2rtT2LAh52jDQSrN0Oyr2JZu6KZiP9 pMD0SLKE9n3KMjgKfUzKKM4gbh4j3M6PTh/jfM0n5PhCXog6toYQbSPq0vioU2O9VhTQ C1K/3ELf+4gMBdU95mFTh1ZmI1CeRu1mg+lFB/we9lWay+HFVqdgKAJm+8hG/nbILgv1 MUcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JtDs5SGs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si1003577ejn.41.2021.03.05.00.10.01; Fri, 05 Mar 2021 00:10:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JtDs5SGs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229526AbhCEIGr (ORCPT + 99 others); Fri, 5 Mar 2021 03:06:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbhCEIGr (ORCPT ); Fri, 5 Mar 2021 03:06:47 -0500 Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0082BC061756 for ; Fri, 5 Mar 2021 00:06:46 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id b8so992401oti.7 for ; Fri, 05 Mar 2021 00:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=6Ntm9TYj9xnK5FJwNfSHccWZk0cH/kRpY9uFJXEGdp4=; b=JtDs5SGsyGwpKyZGB+UWCFD0bUCHtF++4j4LEkMR3zxnUbR7upuo3bGIoFiSGBtExy Xlu/idUZ+1LErYPG3Cd+Eej2W0DQW2t7bP3RcQmpj9eZu4zrngwcstsiZFWkh71eDLt/ +nuDyIl5YfMHCEMynjwMtQeeO6PCpHLId8kJOUlmRAn8t86VTxSa7bVNI5eCWjXFbzhI KCpyR8GReEwx6f8/TqrakkXvX+xSDklxWlzkQs7H9jr7uriW6UvyRmVeN1EPjJMszwh4 sar5jzloP5Iz83AbJ/YuFjSfDDuDnnZOE9T5EQ1HK2xhxG5tmJUpTCiIjgvl02WDu9W+ adnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=6Ntm9TYj9xnK5FJwNfSHccWZk0cH/kRpY9uFJXEGdp4=; b=eHmGIYZc+/PO69dfq8kBNdvXKh1cB9cf9yVvWw7eE5FCzAy/2FGZJNXDYV95AAi+sn g/8SK7oPTFXz07mYXFPL2PQAJfbPFjjN3t4RsxK9d6+Z/+n42YUzpnF0S3fH8j4t8hAS EIXZMl7kEV6tEAeMDg9cssN92Dpadp1ZcQ/oHUT9puR244A5tLhUIGIykfz8JNZ/r/Dj xzTO2dZhFmn06blyezNln6Mzt5zR8FTPSTNzzWSgyIenvvYH63+3PTZAvcRKupGWEoQX IQ+r+ibGmZ3hvUvyaT5X8PCjm3R8Misfpdgp4cEIZWQn0SFBGvhRAglPo2mPfQETYAw4 lYow== X-Gm-Message-State: AOAM533mDegagH+d6Tei3rDCZGjc+6Be21dQ7tfcGEhuVpBaCOVeNb4q de3KAicRpk2Ejm1dApCBrfLZrOZQUOOCNA== X-Received: by 2002:a9d:701e:: with SMTP id k30mr6969214otj.157.1614931606122; Fri, 05 Mar 2021 00:06:46 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d21sm376885oic.54.2021.03.05.00.06.44 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 05 Mar 2021 00:06:45 -0800 (PST) Date: Fri, 5 Mar 2021 00:06:31 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Shakeel Butt cc: Hugh Dickins , Johannes Weiner , Roman Gushchin , Michal Hocko , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] memcg: charge before adding to swapcache on swapin In-Reply-To: <20210304014229.521351-1-shakeelb@google.com> Message-ID: References: <20210304014229.521351-1-shakeelb@google.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Mar 2021, Shakeel Butt wrote: > Currently the kernel adds the page, allocated for swapin, to the > swapcache before charging the page. This is fine but now we want a > per-memcg swapcache stat which is essential for folks who wants to > transparently migrate from cgroup v1's memsw to cgroup v2's memory and > swap counters. In addition charging a page before exposing it to other > parts of the kernel is a step in the right direction. > > To correctly maintain the per-memcg swapcache stat, this patch has > adopted to charge the page before adding it to swapcache. One > challenge in this option is the failure case of add_to_swap_cache() on > which we need to undo the mem_cgroup_charge(). Specifically undoing > mem_cgroup_uncharge_swap() is not simple. > > To resolve the issue, this patch introduces transaction like interface > to charge a page for swapin. The function mem_cgroup_charge_swapin_page() > initiates the charging of the page and mem_cgroup_finish_swapin_page() > completes the charging process. So, the kernel starts the charging > process of the page for swapin with mem_cgroup_charge_swapin_page(), > adds the page to the swapcache and on success completes the charging > process with mem_cgroup_finish_swapin_page(). > > Signed-off-by: Shakeel Butt Quite apart from helping with the stat you want, what you've ended up with here is a nice cleanup in several different ways (and I'm glad Johannes talked you out of __GFP_NOFAIL: much better like this). I'll say Acked-by: Hugh Dickins but I am quite unhappy with the name mem_cgroup_finish_swapin_page(): it doesn't finish the swapin, it doesn't finish the page, and I'm not persuaded by your paragraph above that there's any "transaction" here (if there were, I'd suggest "commit" instead of "finish"'; and I'd get worried by the css_put before it's called - but no, that's fine, it's independent). How about complementing mem_cgroup_charge_swapin_page() with mem_cgroup_uncharge_swapin_swap()? I think that describes well what it does, at least in the do_memsw_account() case, and I hope we can overlook that it does nothing at all in the other case. And it really doesn't need a page argument: both places it's called have just allocated an order-0 page, there's no chance of a THP here; but you might have some idea of future expansion, or matching put_swap_page() - I won't object if you prefer to pass in the page. But more interesting, though off-topic, comments on it below... > +/* > + * mem_cgroup_finish_swapin_page - complete the swapin page charge transaction > + * @page: page charged for swapin > + * @entry: swap entry for which the page is charged > + * > + * This function completes the transaction of charging the page allocated for > + * swapin. > + */ > +void mem_cgroup_finish_swapin_page(struct page *page, swp_entry_t entry) > +{ > /* > * Cgroup1's unified memory+swap counter has been charged with the > * new swapcache page, finish the transfer by uncharging the swap > @@ -6760,20 +6796,14 @@ int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask) > * correspond 1:1 to page and swap slot lifetimes: we charge the > * page to memory here, and uncharge swap when the slot is freed. > */ > - if (do_memsw_account() && PageSwapCache(page)) { > - swp_entry_t entry = { .val = page_private(page) }; > + if (!mem_cgroup_disabled() && do_memsw_account()) { I understand why you put that !mem_cgroup_disabled() check in there, but I have a series of observations on that. First I was going to say that it would be better left to mem_cgroup_uncharge_swap() itself. Then I was going to say that I think it's already covered here by the cgroup_memory_noswap check inside do_memsw_account(). Then, going back to mem_cgroup_uncharge_swap(), I realized that 5.8's 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") removed the do_swap_account or cgroup_memory_noswap checks from mem_cgroup_uncharge_swap() and swap_cgroup_swapon() and swap_cgroup_swapoff() - so since then we have been allocating totally unnecessary swap_cgroup arrays when mem_cgroup_disabled() (and mem_cgroup_uncharge_swap() has worked by reading the zalloced array). I think, or am I confused? If I'm right on that, one of us ought to send another patch putting back, either cgroup_memory_noswap checks or mem_cgroup_disabled() checks in those three places - I suspect the static key mem_cgroup_disabled() is preferable, but I'm getting dozy. Whatever we do with that - and it's really not any business for this patch - I think you can drop the mem_cgroup_disabled() check from mem_cgroup_uncharge_swapin_swap(). > /* > * The swap entry might not get freed for a long time, > * let's not wait for it. The page already received a > * memory+swap charge, drop the swap entry duplicate. > */ > - mem_cgroup_uncharge_swap(entry, nr_pages); > + mem_cgroup_uncharge_swap(entry, thp_nr_pages(page)); > } > - > -out_put: > - css_put(&memcg->css); > -out: > - return ret; > }