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 C8691C43334 for ; Sun, 19 Jun 2022 19:47:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2095B6B0071; Sun, 19 Jun 2022 15:47:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B9B26B0072; Sun, 19 Jun 2022 15:47:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A99D6B0073; Sun, 19 Jun 2022 15:47:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F075A6B0071 for ; Sun, 19 Jun 2022 15:47:48 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id C92E4120A69 for ; Sun, 19 Jun 2022 19:47:48 +0000 (UTC) X-FDA: 79596020616.16.C182523 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf26.hostedemail.com (Postfix) with ESMTP id 4817D1400A2 for ; Sun, 19 Jun 2022 19:47:48 +0000 (UTC) Date: Sun, 19 Jun 2022 12:47:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1655668066; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OmVesAtZj3F0FKl2f4W9KeAOvC/uB1VCNNtyFwxxP9I=; b=OY6DMLII7wiyFQUlghxLigw/dZpLgmKP6un0IhO4Cligy+mRBNPXEPRJwVeV1R4Ul0e3KP Jps9VNA7Gn97vU3YbFrLGWC3b4hV61+aEF3XU2HbFdMzi3kMOb9X7K5HsFDJwbgmhiMs7T 6mkneWt1ousS67WqNBDSmvJflVA5YWg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Muchun Song Cc: hannes@cmpxchg.org, mhocko@kernel.org, shakeelb@google.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, duanxiongchun@bytedance.com, longman@redhat.com Subject: Re: [PATCH v5 08/11] mm: memcontrol: introduce memcg_reparent_ops Message-ID: References: <20220530074919.46352-1-songmuchun@bytedance.com> <20220530074919.46352-9-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220530074919.46352-9-songmuchun@bytedance.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OY6DMLII; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655668068; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OmVesAtZj3F0FKl2f4W9KeAOvC/uB1VCNNtyFwxxP9I=; b=Z01zu//xDZAvFyd6AHtDwWGLtn5/owAl/DxJLBlmCgQ1gYrrLPfSUsdkxoF6L8CAI+gc5I pDt5tLqbwxNx9QaZmto7tALlDnsSJNOWI7hmOWot1k9wMEHnIsXu9jKcVXd2UH2lhyiS8Q kjSCL3ooNSXjZXbQKxWtMwvDM8A7NCE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655668068; a=rsa-sha256; cv=none; b=57laaOG1ESJQV0ne4TsFrHRjWejm22WLiMWtuNyQUN0N00vx8MBgwUkkq8nLOAAAxHAne1 VlCtlhQC9CQu7rgsk5+kgNkyON8MZ8ANowdsyP3XjEKRNpuXtwhcwWTfGa/bhPii/iZnPN hbxVxcZLe1/6NYUT0hPwzfhlcU95Dm8= X-Stat-Signature: bq5a56pe9wsrsrz97onjyx4ne9jy1w5e X-Rspamd-Queue-Id: 4817D1400A2 X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OY6DMLII; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev X-Rspamd-Server: rspam10 X-HE-Tag: 1655668068-61294 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 Mon, May 30, 2022 at 03:49:16PM +0800, Muchun Song wrote: > In the previous patch, we know how to make the lruvec lock safe when LRU > pages are reparented. We should do something like following. > > memcg_reparent_objcgs(memcg) > 1) lock > // lruvec belongs to memcg and lruvec_parent belongs to parent memcg. > spin_lock(&lruvec->lru_lock); > spin_lock(&lruvec_parent->lru_lock); > > 2) relocate from current memcg to its parent > // Move all the pages from the lruvec list to the parent lruvec list. > > 3) unlock > spin_unlock(&lruvec_parent->lru_lock); > spin_unlock(&lruvec->lru_lock); > > Apart from the page lruvec lock, the deferred split queue lock (THP only) > also needs to do something similar. So we extract the necessary three steps > in the memcg_reparent_objcgs(). > > memcg_reparent_objcgs(memcg) > 1) lock > memcg_reparent_ops->lock(memcg, parent); > > 2) relocate > memcg_reparent_ops->relocate(memcg, reparent); > > 3) unlock > memcg_reparent_ops->unlock(memcg, reparent); > > Now there are two different locks (e.g. lruvec lock and deferred split > queue lock) need to use this infrastructure. In the next patch, we will > use those APIs to make those locks safe when the LRU pages reparented. > > Signed-off-by: Muchun Song I've mixed feelings about this: it looks nice, but maybe too nice. I wonder if it's better to open-code it. Not very confident, I wonder what others are thinking. 1) Because the lock callback is first called for all ops, then relocate, then unlock, implicit lock dependencies are created. Now it depends on the order of elements in the memcg_reparent_ops array, which isn't very obvious. 2) Unlikely there will be a lot of new ops added in the future. The code looks correct though. Thanks!