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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D2F9C77B61 for ; Thu, 30 Mar 2023 07:49:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229848AbjC3Hte (ORCPT ); Thu, 30 Mar 2023 03:49:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229798AbjC3Ht0 (ORCPT ); Thu, 30 Mar 2023 03:49:26 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37579659E; Thu, 30 Mar 2023 00:49:09 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 82C051FE96; Thu, 30 Mar 2023 07:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680162547; h=from:from:reply-to: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; bh=zl6vnuhb0+tm4UNYVkua6ap4lB/Vnj1JGtAkmTbyth8=; b=OtqKKjzUcmO/o0IDfFsZZQhAvhs/NKY4kJjUmP4UIDS3us0gtfDjwpZ5/hrmfHWxHHPzpI dZ7X131mCHa/QAdw7J0fEZfW35910RAIMN0WuPe7lYwebuRZiekoQnwdQ8sA+rGDGkzp83 p1Te8uGBUwpnjYZ5L8u7t6zIzW2B6cI= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8A2651348E; Thu, 30 Mar 2023 07:49:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id EG8lH/M+JWRDAgAAMHmgww (envelope-from ); Thu, 30 Mar 2023 07:49:07 +0000 Date: Thu, 30 Mar 2023 09:49:06 +0200 From: Michal Hocko To: Yosry Ahmed , Johannes Weiner Cc: Shakeel Butt , Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Roman Gushchin , Muchun Song , Andrew Morton , Michal =?iso-8859-1?Q?Koutn=FD?= , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Subject: Re: [PATCH v2 4/9] cgroup: rstat: add WARN_ON_ONCE() if flushing outside task context Message-ID: References: <20230328221644.803272-1-yosryahmed@google.com> <20230328221644.803272-5-yosryahmed@google.com> <20230329192059.2nlme5ubshzdbpg6@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu 30-03-23 00:13:16, Yosry Ahmed wrote: > On Thu, Mar 30, 2023 at 12:06 AM Michal Hocko wrote: [...] > > So the real question is. Do we really care so deeply? After all somebody > > might be calling this from within a spin lock or irq disabled section > > resulting in a similar situation without noticing. > > There are discussions in [1] about making atomic rstat flush not > disable irqs throughout the process, so in that case it would only > result in a similar situation if the caller has irq disabled. The only > caller that might have irq disabled is the same caller that might be > in irq context before this series: mem_cgroup_usage(). > > On that note, and while I have your attention, I was wondering if we > can eliminate the flush call completely from mem_cgroup_usage(), and > read the global stats counters for root memcg instead of the root > counters. There might be subtle differences, but the root memcg usage > isn't super accurate now anyway (e.g. it doesn't include kernel > memory). root memcg stats are imprecise indeed and I have to admit I do not really know why we are adding more work for that case. I have tried to dig into git history for that yesterday but couldn't find a satisfying answer. It goes all the way down to 2d146aa3aa842 which has done the switch to rstat. Maybe Johannes remembers. Anyway, back to this particular patch. I still do not see strong reasons to be verbose about !in_task case so I would just drop this patch. -- Michal Hocko SUSE Labs