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 33BD1C433FE for ; Thu, 10 Nov 2022 19:36:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0A406B0071; Thu, 10 Nov 2022 14:36:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ABA056B0072; Thu, 10 Nov 2022 14:36:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 981ED8E0001; Thu, 10 Nov 2022 14:36:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 858FA6B0071 for ; Thu, 10 Nov 2022 14:36:13 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 01E554166D for ; Thu, 10 Nov 2022 19:36:12 +0000 (UTC) X-FDA: 80118538626.19.3C607B3 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf09.hostedemail.com (Postfix) with ESMTP id 986C4140007 for ; Thu, 10 Nov 2022 19:36:11 +0000 (UTC) Received: by mail-io1-f42.google.com with SMTP id n191so2043695iod.13 for ; Thu, 10 Nov 2022 11:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tzjw3odtvlQil/jHlpnewBAjOSpFW5cV80T6OAYFKjY=; b=iuaYqdwZM/0oCPWc93mIY0NicjiJhw7/rvxeaarjT1Tqf5ZHSLmKsKcf7baqlRZzGW 48G7ydGLqDDqE6J6z5KkTZTsT6IPlVP9/NuCrbkuyC0ICfrf0mTe64olZVw4TUCHsHMz exlcuIbh+46O5BTFQ7fbnEIKz+5LZav8ff5cDQmxpnLZa4hPCawhSu8wtZ25bYO3uJCY yo/PRhoXv3c4U/NLMsEsT/3BfQJPlZcpCrHjsgK3t47W6BptStFIaAV97x3GKxq3sQF/ ArH6DTw1RQswDn2xtHiVHAZhACBR/S7NMkmMMP+mUCvFTFHflwGVYX8uEDZ5rbAAicnY H9ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tzjw3odtvlQil/jHlpnewBAjOSpFW5cV80T6OAYFKjY=; b=znxJ/l+6t+cR/GAg4NuKVDq6w1m2d97HRRMMG5CPZYvCnnu0S4uAJfaWtya6OwGt7Q ifIvMnai0NJPSU66hGDAqPzqhGKWjx+utBEGxZ5ZsNAXNOCmvDAo0iNFJhRMakk83Wy0 4PnyPbeV9dMZzJlzajlkdFvHr6Ncke19b4es4Scx2zNJPRkaydBKiOEDq5abdudm+AB1 iSl6srA+b0QiBICHiAZ/gjMoNeiKDgtjPst0RKXx7vxbX7/qAi/JzJqo59Dq59OVhvQ0 AVlQnOZQGMMjotkSspTgv45/Eqg8tpm9j0dhxyvI9tNmVZLAW624XtB7AMAy3nbHHSSA 32VQ== X-Gm-Message-State: ACrzQf3eBJ4HEhRhKBw+jJinR853xOVTP6IN+5rbgoGdbs5SEXsCuJI9 ifdGrP12p8yItBdtVkYdzbj+9UUDoiae98V98b5UAQ== X-Google-Smtp-Source: AMsMyM5GN5HdlamsR5UN+KbvUSB3LPRGSiwNUFNx5ocIJVw5vHYrJHTFCeeh4JJGj4nGoqQ/uCr7MisQ7VCz7xr7kYg= X-Received: by 2002:a05:6638:1a8f:b0:375:1ad6:e860 with SMTP id ce15-20020a0566381a8f00b003751ad6e860mr3684660jab.191.1668108970639; Thu, 10 Nov 2022 11:36:10 -0800 (PST) MIME-Version: 1.0 References: <20221110065316.67204-1-lujialin4@huawei.com> <20221110144243.GA10562@blackbody.suse.cz> In-Reply-To: <20221110144243.GA10562@blackbody.suse.cz> From: Yosry Ahmed Date: Thu, 10 Nov 2022 11:35:34 -0800 Message-ID: Subject: Re: [PATCH] mm/memcontrol.c: drains percpu charge caches in memory.reclaim To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Lu Jialin , Johannes Weiner , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iuaYqdwZ; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668108971; a=rsa-sha256; cv=none; b=8eb4uopdKOFxxf9NSxmDDBQUNuN6YEnxRZvb9+5yyJELztPCjcIjMUogaJ3BHEC3uP9WMo ySv15b3T5cffbxiDCfdsh7igAYau5CTf29QKupufjlQYeBYrp4fQ2NZt+zgPb9WBTuEHFd tQIqQAuqmCESip9cjaClvqpof+ab3O0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668108971; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tzjw3odtvlQil/jHlpnewBAjOSpFW5cV80T6OAYFKjY=; b=huBv0wGmvKM7qYn3egDbnYR1mUCRXPCRB/3LIDdudVXpNMWhlqg9pJVOtLqh1BB26tNBSq GyuDuHrocRvTj0ZJJSEFP4Ya9lMFJBMghKqrTa3xFRA1R8xkr3YvGJ2+AakdyKha26UMSz MtSQFT8rG8/bFVNrVavY1Zk/PBkuAq8= X-Stat-Signature: twnrkw6yjth6gwae36ck955isgrpfxkt X-Rspamd-Queue-Id: 986C4140007 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iuaYqdwZ; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1668108971-93809 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 Thu, Nov 10, 2022 at 6:42 AM Michal Koutn=C3=BD wrote= : > > Hello Jialin. > > On Thu, Nov 10, 2022 at 02:53:16PM +0800, Lu Jialin wrote: > > When user use memory.reclaim to reclaim memory, after drain percpu lru > > caches, drain percpu charge caches for given memcg stock in the hope > > of introducing more evictable pages. > > Do you have any data on materialization of this hope? > > IIUC, the stock is useful for batched accounting to page_counter but it > doesn't represent real pages. I.e. your change may reduce the > page_counter value but it would not release any pages. Or have I missed > a way how it helps with the reclaim? +1 It looks like we just overcharge the memcg if the number of allocated pages are less than the charging batch size, so that upcoming allocations can go through a fast accounting path and consume from the precharged stock. I don't understand how draining this charge may help reclaim. OTOH, it will reduce the page counters, so if userspace is relying on memory.current to gauge how much reclaim they want to do, it will make it "appear" like the usage dropped. If userspace is using other signals (refaults, PSI, etc), then we would be more-or-less tricking it into thinking we reclaimed pages when we actually didn't. In that case we didn't really reclaim anything, we just dropped memory.current slightly, which wouldn't matter to the user in this case, as other signals won't change. The difference in perceived usage coming from draining the stock IIUC has an upper bound of 63 * PAGE_SIZE (< 256 KB with 4KB pages), I wonder if this is really significant anyway. > > Thanks, > Michal