Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1073768rwb; Thu, 1 Dec 2022 12:01:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf4F/5IWR6jxeogFznldKDqQHNbXYFt0/kNSwuyYKgWWLp5BFM9qTH9Bya9Cy+SkR6CRnVQQ X-Received: by 2002:aa7:dd4b:0:b0:467:65a2:f635 with SMTP id o11-20020aa7dd4b000000b0046765a2f635mr48555106edw.106.1669924871457; Thu, 01 Dec 2022 12:01:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669924871; cv=none; d=google.com; s=arc-20160816; b=FtwZvScSvxbe/xrN0x2ebZYFC2ULowf1SFOgiRJlG8KFPKp9JKe7v1OwGJ39+zxOu1 fKjLipAsXGvAY2MnQVMremMEtiLy3dQ9aJThoq7/XkOBI5XpbXAmDZmOfqcsR/wTCojm vzv3ZhBZoF/dfZKYMdhgZ3i1vmnkeawi8lqmZHni0DlYaHRjfus786bQbh/QdgQf8R3Y NdyY5YNoql07HiWSsrG/tV9uTC8luEV+DSnNNZ+QbhPN+p620USl1QGUSgdqYlQIKvVr haWpjpDxZtNemrPsCVcyy2QtHRNVPm/ildXooXHPkc3NYOd4NQyfzE1czk63p0wRqS+C zTYQ== 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; bh=zhByeDjVn2aoQqM4RcyM2NkEV3uIRzNk3+iOiMHEoNk=; b=MNReydAAzINZp+52ilTYj7vawmqEiILfuMuPY3pmISGb8LslRxSKlWSU2NNXroWRNb wt6HCEf5VF5IFc16fCIv8UHvzk8UATA/OsV0054kxaNM2efyI3l3jOI3jL2WEbAm1DNE WOh4wA69Q+FOEgZaje1HXTaXMCU4mG2ZpuFFGlOxP+L41sYZHtcqsBUVW7qkamConvde tyO1lMicustn0PjxkXjYDMe/ySd/9weJ/p4U/bxrCBmA7B6Kmzfqokb0AZJRJeIdzOTl R7V9VU2gsFGrj0GQ92nOn/yzJZhn1EpjTKihkKSHvIcQc2EI6IImUxe+zuGR4K/N2rXh 1vSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a3-20020a1709066d4300b007aa6262f627si3223893ejt.640.2022.12.01.12.00.49; Thu, 01 Dec 2022 12:01:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229999AbiLATYl (ORCPT + 82 others); Thu, 1 Dec 2022 14:24:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229775AbiLATYk (ORCPT ); Thu, 1 Dec 2022 14:24:40 -0500 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70497BE6A7 for ; Thu, 1 Dec 2022 11:24:39 -0800 (PST) Date: Thu, 1 Dec 2022 11:24:19 -0800 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Michal Hocko Cc: kernel test robot , Shakeel Butt , oe-lkp@lists.linux.dev, lkp@intel.com, Andrew Morton , kernel test robot , Soheil Hassas Yeganeh , Feng Tang , Muchun Song , Eric Dumazet , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , linux-kernel@vger.kernel.org Subject: Re: [linus:master] [memcg] 1813e51eec: kernel-selftests.cgroup.test_kmem.test_kmem_memcg_deletion.fail Message-ID: References: <202212010958.c1053bd3-yujie.liu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 01, 2022 at 11:16:34AM +0100, Michal Hocko wrote: > On Thu 01-12-22 16:05:44, kernel test robot wrote: > > Greeting, > > > > FYI, we noticed kernel-selftests.cgroup.test_kmem.test_kmem_memcg_deletion.fail due to commit (built with gcc-11): > > > > commit: 1813e51eece0ad6f4aacaeb738e7cced46feb470 ("memcg: increase MEMCG_CHARGE_BATCH to 64") > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > > > [test failed on linux-next/master 700e0cd3a5ce6a2cb90d9a2aab729b52f092a7d6] > > > > in testcase: kernel-selftests > > version: kernel-selftests-x86_64-2ed09c3b-1_20221128 > > with following parameters: > > > > group: cgroup > > > > test-description: The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel. > > test-url: https://www.kernel.org/doc/Documentation/kselftest.txt > > > > on test machine: 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice Lake) with 128G memory > > > > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): > > > > > > # memory.current = 40161280 > > # slab + anon + file + kernel_stack = 14478624 > > # slab = 13453184 > > # anon = 0 > > # file = 0 > > # kernel_stack = 0 > > # pagetables = 0 > > # percpu = 1025440 > > # sock = 0 > > # not ok 2 test_kmem_memcg_deletion <-- > > # ok 3 test_kmem_proc_kpagecgroup > > # ok 4 test_kmem_kernel_stacks > > # ok 5 test_kmem_dead_cgroups > > # ok 6 test_percpu_basic > > not ok 2 selftests: cgroup: test_kmem # exit=1 > > IIUC we need this > diff --git a/tools/testing/selftests/cgroup/test_kmem.c b/tools/testing/selftests/cgroup/test_kmem.c > index 22b31ebb3513..1d073e28254b 100644 > --- a/tools/testing/selftests/cgroup/test_kmem.c > +++ b/tools/testing/selftests/cgroup/test_kmem.c > @@ -24,7 +24,7 @@ > * the maximum discrepancy between charge and vmstat entries is number > * of cpus multiplied by 32 pages. > */ > -#define MAX_VMSTAT_ERROR (4096 * 32 * get_nprocs()) > +#define MAX_VMSTAT_ERROR (4096 * 64 * get_nprocs()) Yep. > > > static int alloc_dcache(const char *cgroup, void *arg) > > But honestly, I am rather dubious of tests like this one. Does it really > give us any useful testing coverage? As I remember, we've had some issues in the past when some memcg stats leftovers were not prpoerly propagated on the cgroup deletion, so that over time the numbers on the parent level beacame completely crazy. Thanks!