Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2261946pxb; Fri, 5 Mar 2021 11:02:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOwqNkQVEhuthmFlYJ4zZ9s50rBvaOG+Rq28GjI4mMHhNUirVRPkt7DhKQeCB8EHpQZbUQ X-Received: by 2002:aa7:cd8d:: with SMTP id x13mr10475259edv.286.1614970946389; Fri, 05 Mar 2021 11:02:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614970946; cv=none; d=google.com; s=arc-20160816; b=UvIx5wCo061WnH4tnh9tJhJj/ewf+xj29k52eCZXuaHOW8XFbhRKCpIRD+tEIgE+/3 Z0fnBPUlH4rawoaonaVt4D4zK0I6Yon5Sb0vh7XIrtzKkb5hh3pqWwXcvxLUKbrhGbPR CZAQcvkc3KS2+5j3EXtUUdTQdr2+Q45CLPi0eXq93QpCUUosdJFSmJqKMAkv+e6dOM+N pdBfJOmX7iWRorfxkZ+G9PkcTAOsGipX/KLjEZI5V2B0DRDNHk39gg/xBnzZAibs7R9f 51sfi7HE9YeC+fSc32PeiGO26Ok6GBGSGU0h/aDywHnjOD3fLYsHYwSfF8J0kStXm/Iu xhtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=rBJywJ/55SdNNzhqEcBb4hZL99EvDvjWTnWLT8JPIUw=; b=tHhlDsk5JNuyWzKH00ydgTXQYYziA6mASRz1opfVB5nNHbSwxYztKeHGLw0oFuhY1Q 73NFAGRgaKTuX4dQG3ZTkqZF6KCo2t43nSUb7YRto4X9IppVDm6avX7zfJi4FsQhDu3F lHv6iFybRPTpIog5cbAGfddvIaLAmwFWV22DFC5ERKYvVqMnUDGrukn2pRkUosRk2+Qj tKNVBNoLUhkque9IWfK0N99R13P8NCuKbtp4joWMdOmeqfdlCJXqWGBxmCHJdveNNoaG aErl7oERwYsiZ262J+hba/93AEEujDpNtl/31kytEqkG8/D/12tqY9D/q9Ah/TwxU8Oe slyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="RoBRx/Ju"; 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 y13si2077597edm.557.2021.03.05.11.02.04; Fri, 05 Mar 2021 11:02:26 -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="RoBRx/Ju"; 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 S229818AbhCETA6 (ORCPT + 99 others); Fri, 5 Mar 2021 14:00:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229740AbhCETAz (ORCPT ); Fri, 5 Mar 2021 14:00:55 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8CDCC061756 for ; Fri, 5 Mar 2021 11:00:54 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id n16so5388837lfb.4 for ; Fri, 05 Mar 2021 11:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rBJywJ/55SdNNzhqEcBb4hZL99EvDvjWTnWLT8JPIUw=; b=RoBRx/Ju+scxCBTVd/KvQrJIbS48I+xnjFvh4bTmMOSNIxQ5JM+JiCXo3NaDckbE9M DCZOWmAjHLYlX+7BObWmlV2P6zUj25fU/3weEb+3W5YxaOZgDWeus+AMMuY/jCLgLbH/ Vpi+6D4B/nRB2tiuuyiNPmfxiMVKU5PB6VhT09Ls9yc41FsKwAwBlS1xHhpAjVwHtXkZ NH7VYMRF+Qpbw7xrXRbxVz1JGegIJ1ZstGik6Q8xIWI91LWicEzNIhUkJhwBRiL/9BXU lTjrxy8IvulF0o22LYBTRU4oz2GuDEKwqyQgwfFPXW20DoV+1kPFGXVXJT24zB1F4txg 3J7g== 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; bh=rBJywJ/55SdNNzhqEcBb4hZL99EvDvjWTnWLT8JPIUw=; b=L3CnuPnEaXRkPxYHJoYZdQ9Li52ggXSloejR8GJG2qDvKub59szF3e/HRTiSShKSB0 WEwvK95zwjTIe36NDVRyWPFv/JR1v/b95wT/upcTvfYs92e2ypiAyqMsdpk7F2TVxRZx qrZd5YPSTAkQGspi1LfwcqTpaMMcdK64rL5D4l6HAAqO7ordmh5ujTMHvEnnbso7mFDf JFUyUut1ud0ZDwsjXOBz3ubWWO/VMtXrlt6vDnGAfhBTR31Zt3ksW2YC92p2V8XyyhO1 vQIWv3jswZusVpg53MUzEJTBUHmj23rffjanGNeXw7ZDDxah5WqjJS1LDBbNwe20AN8G DNzA== X-Gm-Message-State: AOAM531CR2G80bphQR19khdT3ugxHbR+31toOUsBPrS/UghuQkAAMsLQ M6l6727BeW3QHok3xJ3w48Dofz76UcCwMyNktF8fHw== X-Received: by 2002:ac2:4144:: with SMTP id c4mr6344311lfi.549.1614970852892; Fri, 05 Mar 2021 11:00:52 -0800 (PST) MIME-Version: 1.0 References: <20210304014229.521351-1-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Fri, 5 Mar 2021 11:00:40 -0800 Message-ID: Subject: Re: [PATCH v3] memcg: charge before adding to swapcache on swapin To: Johannes Weiner Cc: Hugh Dickins , Roman Gushchin , Michal Hocko , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 5, 2021 at 8:25 AM Johannes Weiner wrote: > > On Fri, Mar 05, 2021 at 12:06:31AM -0800, Hugh Dickins wrote: > > 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. > > Yes, that's better. The sequence is still somewhat mysterious for > people not overly familiar with memcg swap internals, but it's much > clearer for people who are. > > I mildly prefer swapping the swapin bit: > > mem_cgroup_swapin_charge_page() > mem_cgroup_swapin_uncharge_swap() > > But either way works for me. > I will do a coin toss to select one. > > 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. > > Agreed. Will remove the page parameter. BTW I will keep mem_cgroup_disabled() check in the uncharge swap function as I am thinking of removing "swapaccount=0" functionality.