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 X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37F1BC43461 for ; Wed, 16 Sep 2020 18:58:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9F2B20732 for ; Wed, 16 Sep 2020 18:58:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jntgCgVM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9F2B20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ECB326B0082; Wed, 16 Sep 2020 14:58:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7AEE6B0083; Wed, 16 Sep 2020 14:58:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D91D56B0085; Wed, 16 Sep 2020 14:58:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id AF8446B0082 for ; Wed, 16 Sep 2020 14:58:41 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 663378249980 for ; Wed, 16 Sep 2020 18:58:41 +0000 (UTC) X-FDA: 77269836042.24.crush76_221631b2711c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 381051A4A0 for ; Wed, 16 Sep 2020 18:58:41 +0000 (UTC) X-HE-Tag: crush76_221631b2711c X-Filterd-Recvd-Size: 5516 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Sep 2020 18:58:40 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id n14so4523972pff.6 for ; Wed, 16 Sep 2020 11:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZHnOyfd11fuaDMHJEA6fIG0O9TIwpb3umMctEKX/Vyg=; b=jntgCgVMXGda+8BFGAlrv5AGNNV+QQO8b6bEf34x5C5VztwL6t/++yyRtt8TGIRpVg 86b0/zRlb0ZZTCNXyrF2M5IvyQ4R3jvGkWJrkr7EGimz+Rmw9XGwoJ6NYFpw1Q7tU3ZJ Z4oISOPdku2hodf3uTl2hHJCPh3rpLL06/G9souJroutxnNlCC8i6iA+wdU+8hf5PuYD Emag8dE+GpqE+6EZ7lmjkcnTpyD+V1CR8nflGL0GXwO/s9BOrOgXty4eJljvA4TvI+t8 R4/YJHbQxPgcv2jJKIWX4envYmzl3GhzK/GmSKpfyNZTJRmPeQd2OI97kq+P/Ca2RSG4 kS2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZHnOyfd11fuaDMHJEA6fIG0O9TIwpb3umMctEKX/Vyg=; b=Z1LbhgXmNci4TYwsfwV/8p3WaEyp8KV376Np7A+GkITVqom/LG7Km+cZhRLpwjZEkF O/Dk5Ql0IUA1coN0ZpCkIAMoW+Y3v+P+3octzhrZeNlFmrLrMBObaF+B4ejBfyf6SD8o fY+aB2gq3ntd6DinTOc3HqvoHuLUpD97nRe2hZjSeEJLoApabhTYTLxjhGYZxOnK7AtU vUBolMuQNevWLYNwoAlkz6ST7DOX0uBkWNccQemvAnC24Y1GENUQTAJlCmPL2rKaW0x0 P9aY9HdL+qEi2+fPsCsBcvgDkpJuxxxgPo7up6OdwKCzpriLCRFPRLJFuhdx/NtTV3Rb R07Q== X-Gm-Message-State: AOAM533s5/MS+a/fgvzRHnTkQ6EHtLjfXqMOjgkLqp0vE7mXUCdNSjAi dM3yPc2sjriGb8BqkMCZAzRFkyTa9NE= X-Google-Smtp-Source: ABdhPJyqp7mEXldM+Vzl4EMfrIFN6GkSxZha6QOteU6DVv2b9Vn5CZJwinly18mWEQKG7fBdWdFwWw== X-Received: by 2002:a63:6246:: with SMTP id w67mr242623pgb.344.1600282719147; Wed, 16 Sep 2020 11:58:39 -0700 (PDT) Received: from localhost.localdomain (c-107-3-138-210.hsd1.ca.comcast.net. [107.3.138.210]) by smtp.gmail.com with ESMTPSA id fz23sm3453747pjb.36.2020.09.16.11.58.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 11:58:37 -0700 (PDT) From: Yang Shi To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Cc: shy828301@gmail.com, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/2] Remove shrinker's nr_deferred Date: Wed, 16 Sep 2020 11:58:21 -0700 Message-Id: <20200916185823.5347-1-shy828301@gmail.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Rspamd-Queue-Id: 381051A4A0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 Content-Transfer-Encoding: quoted-printable 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: Recently huge amount one-off slab drop was seen on some vfs metadata heav= y workloads, it turned out there were huge amount accumulated nr_deferred objects seen= by the shrinker. I managed to reproduce this problem with kernel build workload plus negat= ive dentry generator. First step, run the below kernel build test script: NR_CPUS=3D`cat /proc/cpuinfo | grep -e processor | wc -l` cd /root/Buildarea/linux-stable for i in `seq 1500`; do cgcreate -g memory:kern_build echo 4G > /sys/fs/cgroup/memory/kern_build/memory.limit_in_bytes echo 3 > /proc/sys/vm/drop_caches cgexec -g memory:kern_build make clean > /dev/null 2>&1 cgexec -g memory:kern_build make -j$NR_CPUS > /dev/null 2>&1 cgdelete -g memory:kern_build done That would generate huge amount deferred objects due to __GFP_NOFS alloca= tions. Then run the below negative dentry generator script: NR_CPUS=3D`cat /proc/cpuinfo | grep -e processor | wc -l` mkdir /sys/fs/cgroup/memory/test echo $$ > /sys/fs/cgroup/memory/test/tasks for i in `seq $NR_CPUS`; do while true; do FILE=3D`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 64= ` cat $FILE 2>/dev/null done & done Then kswapd will shrink half of dentry cache in just one loop as the belo= w tracing result showed: kswapd0-475 [028] .... 305968.252561: mm_shrink_slab_start: super_cach= e_scan+0x0/0x190 0000000024acf00c: nid: 0 objects to shrink 4994376020 gfp_flags GFP_KERNEL cache items 93689873 de= lta 45746 total_scan 46844936 priority 12 kswapd0-475 [021] .... 306013.099399: mm_shrink_slab_end: super_cache_= scan+0x0/0x190 0000000024acf00c: nid: 0 unused scan count 4994376020 new scan count 4947576838 total_scan 8 last shrinke= r return val 46844928 There were huge deferred objects before the shrinker was called, the beha= vior does match the code but it might be not desirable from the user's stand of point. IIUC the deferred objects were used to make balance between slab and page= cache, but since commit 9092c71bb724dba2ecba849eae69e5c9d39bd3d2 ("mm: use sc->priority for slab = shrink targets") they were decoupled. And as that commit stated "these two things have nothing= to do with each other". So why do we have to still keep it around? I can think of there might be= huge slab accumulated without taking into account deferred objects, but nowadays the most workl= oads are constrained by memcg which could limit the usage of kmem (by default now), so it seems m= aintaining deferred objects is not that useful anymore. It seems we could remove it to simpl= ify the shrinker logic a lot. I may overlook some other important usecases of nr_deferred, comments are= much appreciated.