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 90351C433EF for ; Tue, 15 Mar 2022 08:54:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ACF88D0003; Tue, 15 Mar 2022 04:54:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25C328D0001; Tue, 15 Mar 2022 04:54:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14C088D0003; Tue, 15 Mar 2022 04:54:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 08AC88D0001 for ; Tue, 15 Mar 2022 04:54:37 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B91038249980 for ; Tue, 15 Mar 2022 08:54:36 +0000 (UTC) X-FDA: 79246009752.17.553535E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id 4AE2D12000E for ; Tue, 15 Mar 2022 08:54:36 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 2DBF11F37E; Tue, 15 Mar 2022 08:54:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1647334475; h=from:from:reply-to: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=k31i3YTYOknR6WudpStCLK3nsIiTUhJ3ISWvBqEKH3c=; b=MbRJiBppXoWjXQRAq5YT4P81gpSS9nnDeHUj39iWUP03PZNHRGvEtD9vEojB4gfNUXN5Tk q1LeMjApOhbLSoOL8PiC0wlPgYbx+84b9+vVeLizG7aHNkZNeY/f8eATrszIWFxIJgUrmx cpuR7rDMXVxNY37C7t4Yl3/HUvYFjDw= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id EBC00A3B87; Tue, 15 Mar 2022 08:54:34 +0000 (UTC) Date: Tue, 15 Mar 2022 09:54:34 +0100 From: Michal Hocko To: Wei Yang Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [Patch v2 3/3] mm/memcg: add next_mz back to soft limit tree if not reclaimed yet Message-ID: References: <20220312071623.19050-1-richard.weiyang@gmail.com> <20220312071623.19050-3-richard.weiyang@gmail.com> <20220314230548.wo4colcwqxhhf3mx@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220314230548.wo4colcwqxhhf3mx@master> X-Rspamd-Queue-Id: 4AE2D12000E X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MbRJiBpp; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Stat-Signature: 7mj3gos1891ax6g5jegz6bhaq6ouyk77 X-Rspamd-Server: rspam04 X-HE-Tag: 1647334476-121272 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 14-03-22 23:05:48, Wei Yang wrote: > On Mon, Mar 14, 2022 at 10:41:13AM +0100, Michal Hocko wrote: > >On Sat 12-03-22 07:16:23, Wei Yang wrote: > >> When memory reclaim failed for a maximum number of attempts and we bail > >> out of the reclaim loop, we forgot to put the target mem_cgroup chosen > >> for next reclaim back to the soft limit tree. This prevented pages in > >> the mem_cgroup from being reclaimed in the future even though the > >> mem_cgroup exceeded its soft limit. > >> > >> Let's say there are two mem_cgroup and both of them exceed the soft > >> limit, while the first one is more active then the second. Since we add > >> a mem_cgroup to soft limit tree every 1024 event, the second one just > >> get a rare chance to be put on soft limit tree even it exceeds the > >> limit. > > > >yes, 1024 could be just 4MB of memory or 2GB if all the charged pages > >are THPs. So the excess can build up considerably. > > > >> As time goes on, the first mem_cgroup was kept close to its soft limit > >> due to reclaim activities, while the memory usage of the second > >> mem_cgroup keeps growing over the soft limit for a long time due to its > >> relatively rare occurrence. > >> > >> This patch adds next_mz back to prevent this sceanrio. > >> > >> Signed-off-by: Wei Yang > > > >Even though your changelog is different the change itself is identical to > >https://lore.kernel.org/linux-mm/8d35206601ccf0e1fe021d24405b2a0c2f4e052f.1613584277.git.tim.c.chen@linux.intel.com/ > >In those cases I would preserve the the original authorship by > >From: Tim Chen > >and add his s-o-b before yours. > > TBH I don't think this is fair. > > I didn't see his original change before I sent this patch. This is a > coincidence we found the same point for improvement. > > It hurts me if you want to change authorship. Well, if you really thinks this > is what it should be, please remove my s-o-b. OK, fair enough. -- Michal Hocko SUSE Labs