Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1610056pxb; Thu, 4 Mar 2021 16:16:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3ydSdMQQDr/uIKJKsWTIa6pVtgHZM/Pbsu7CTJCcX8BBM45UX6tHVSkI95DJCPf1ERhfC X-Received: by 2002:a6b:4109:: with SMTP id n9mr5572472ioa.43.1614903401915; Thu, 04 Mar 2021 16:16:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614903401; cv=none; d=google.com; s=arc-20160816; b=bbVxdWexCYxV51IfeaCovTCDoRCIUf8+JSYan/eu4rUhnutoe/A+gtoap4LaXsRUBR HZOpL2EeaMB8OArVItm9ybYnwYeJsY+x1zh7Xosw/8Tz2eNuSIUCuoab3x6b7SyPgl/+ GdFwyItPRoitLqFEttjfQ2TBwjul8qj9rcfLI4kkszNd4kN7vL8QToC/545uBVpYyfyP WScaoBPittqlgszDSUovltnPBZ4XhhstHDQn134sq0OHw7nowUanviLKB344ywNZY8Pr q42YVaop9p5ngEWt57+LtRV+8+ViccL/w5IQ2dZnxADHItmS/gr3HNxAMaHcSV9jJk3z 86nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BPzzifR3jmKfmhbVLe6vXoybjuDrovQTeCnMZN/atRQ=; b=RQVlTpsp94t3CQXK958TsmObAw5JUilNDgmVTuCZ4OBBfx4EYCljXV8b4+kpLazIPd WTO2nV0cce/hBHcPkC3egJBRUeQvW5n/x9lHN9IAEgCNbYL5BgngCcdpurtMxuIMqF1i 2+sju+Eszf+Y/UPDDkPTH3QKu0WncENgwGB+mdAxgTA7mlxLTwBYAXSzKCIGTIK9pQkl nco/LKx39JtYlGgyVSdtjaY08nysXlBJ01dTfjOp0yVqqWILMVksDg8UlHtlmjrgpcn1 IRzdoPsErKG2olBdRxZAvwa57hHNKcAtobnzjjtrwMo7eGJYD7MlROu3tft5OQLe9taa mgZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=WWef2GAf; 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=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b1si785324ioj.56.2021.03.04.16.16.28; Thu, 04 Mar 2021 16:16:41 -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=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=WWef2GAf; 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=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235671AbhCDPtl (ORCPT + 99 others); Thu, 4 Mar 2021 10:49:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235678AbhCDPtN (ORCPT ); Thu, 4 Mar 2021 10:49:13 -0500 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F67FC061574 for ; Thu, 4 Mar 2021 07:48:33 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id b130so16578699qkc.10 for ; Thu, 04 Mar 2021 07:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BPzzifR3jmKfmhbVLe6vXoybjuDrovQTeCnMZN/atRQ=; b=WWef2GAfbou80N5BMcLGOfy0SRUKVjvprQBlt+eQ+fl9znRom4oEqDUkcVMMFRhCsH HsSgPUCsRxtfs2w2UEYQT8vJ7rEWDZ2ACkOnMGQe65sLG88PHpR+1P/F+9hK0PA7JVeG 7UuWOMl76v8wjCcKe7UDA5MFirmoqXx4dzCu/bQ3QKktRLHNXPLldgF4/HqlPEFukYzz vrmARnzD/btz1fvFlMRfqt0RDiFQX5hbc2fi1W0JrT8ItDNEy+F/ItC7C9js8zRa2q9Y Mld0Q+guocOpuvIvtAEx8d0GvDnv1b/zleQfkTOv0IL7WjOCaqoUCmjMVWgUCbcSx4Lv k/RA== 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=BPzzifR3jmKfmhbVLe6vXoybjuDrovQTeCnMZN/atRQ=; b=b4z5jS51/zWe6i/1YR6+Cv2nvmmpUadh+87/VRfeziQK3TQ4z06WgwwPfXctkyhbXI qeuQlkQTak/jL+6M5uyvpg+m038q4flpZjNZS6ew2pxu6k2pogwAfYYkRZOrOdpljFMG VtTbdNSrZy+ka4BXKNrXjPvgJfr9JUwlDoeR87I0sjOq6PAtK+zZPmDoiXHcDf+4LkJG Aa8GO54NvR6E0blas3J9OJb/vgdygR3PBmfh2BBzk8CCmDnsaHZcosXg6phZcf9CC8eY NFmBMjFX3LiGXgQEYfu8TE0aRT7hhFecxwQJymoD2654uwZor0klUGo9GFjtvM5nVW8+ uZgQ== X-Gm-Message-State: AOAM531RyP23NRMEsUFtXbJIj8yIQ2hGTRHlZ0OPBdpssMtqHbAwXIGl tyGHZXMFDlAr204fJJnS95d7Dw== X-Received: by 2002:a37:4e01:: with SMTP id c1mr4577182qkb.16.1614872912480; Thu, 04 Mar 2021 07:48:32 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:b28e]) by smtp.gmail.com with ESMTPSA id h3sm15841551qtp.8.2021.03.04.07.48.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Mar 2021 07:48:31 -0800 (PST) Date: Thu, 4 Mar 2021 10:48:30 -0500 From: Johannes Weiner To: Shakeel Butt Cc: Hugh Dickins , 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 Message-ID: References: <20210304014229.521351-1-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304014229.521351-1-shakeelb@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 03, 2021 at 05:42:29PM -0800, 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 The patch looks good to me, I have just a minor documentation nit below. But with that addressed, please add: Acked-by: Johannes Weiner > +/** > + * mem_cgroup_charge_swapin_page - charge a newly allocated page for swapin > + * @page: page to charge > + * @mm: mm context of the victim > + * @gfp: reclaim mode > + * @entry: swap entry for which the page is allocated > + * > + * This function marks the start of the transaction of charging the page for > + * swapin. Complete the transaction with mem_cgroup_finish_swapin_page(). > + * > + * Returns 0 on success. Otherwise, an error code is returned. > + */ > +int mem_cgroup_charge_swapin_page(struct page *page, struct mm_struct *mm, > + gfp_t gfp, swp_entry_t entry) > +{ > + struct mem_cgroup *memcg; > + unsigned short id; > + int ret; > > - if (!memcg) > - memcg = get_mem_cgroup_from_mm(mm); > + if (mem_cgroup_disabled()) > + return 0; > > - ret = try_charge(memcg, gfp_mask, nr_pages); > - if (ret) > - goto out_put; > + id = lookup_swap_cgroup_id(entry); > + rcu_read_lock(); > + memcg = mem_cgroup_from_id(id); > + if (!memcg || !css_tryget_online(&memcg->css)) > + memcg = get_mem_cgroup_from_mm(mm); > + rcu_read_unlock(); > > - css_get(&memcg->css); > - commit_charge(page, memcg); > + ret = __mem_cgroup_charge(page, memcg, gfp); > > - local_irq_disable(); > - mem_cgroup_charge_statistics(memcg, page, nr_pages); > - memcg_check_events(memcg, page); > - local_irq_enable(); > + css_put(&memcg->css); > + return ret; > +} > > +/* > + * 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. It's possible somebody later needs to change things around in the swapin path and it's not immediately obvious when exactly these two functions need to be called in the swapin sequence. Maybe add here and above that charge_swapin_page needs to be called before we try adding the page to the swapcache, and finish_swapin_page needs to be called when swapcache insertion has been successful?