From patchwork Wed Sep 16 18:58:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Shi X-Patchwork-Id: 11780495 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6CB956CA 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 0809920809 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 0809920809 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) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id E7AEE6B0083; Wed, 16 Sep 2020 14:58:41 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org 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-Original-To: linux-mm@kvack.org 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-Spam-Summary: 1,0,0,96973fa1da746474,d41d8cd98f00b204,shy828301@gmail.com,,RULES_HIT:41:355:379:541:968:973:982:988:989:1202:1260:1311:1314:1345:1437:1515:1535:1542:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2693:2890:3138:3139:3140:3141:3142:3354:3653:3865:3866:3867:3868:3870:3871:3872:3874:4041:4042:4321:4605:5007:6119:6120:6261:6653:7903:9121:9413:10004:11026:11233:11657:11658:11914:12043:12050:12295:12296:12297:12438:12517:12519:12555:12986:13161:13229:13869:13894:14096:14687:14721:21080:21444:21450:21627:21666:21740:21795:21990:30001:30005:30012:30054:30090,0,RBL:209.85.210.193:@gmail.com:.lbl8.mailshell.net-66.100.201.100 62.50.0.100;04yg8pa3puak6yydjgmhsdbfyuj39opf4r7cuyh8bisbdgmztyprqnw3ie55fwa.uu8r5h16nukdrcmhrb3p3pzf3ofzbcpcgnya3ia35nkg7idu1pzji6aouip8jj8.a-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:23,LUA_SUMMARY:none 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 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 heavy 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 negative dentry generator. First step, run the below kernel build test script: NR_CPUS=`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 allocations. Then run the below negative dentry generator script: NR_CPUS=`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=`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 below tracing result showed: kswapd0-475 [028] .... 305968.252561: mm_shrink_slab_start: super_cache_scan+0x0/0x190 0000000024acf00c: nid: 0 objects to shrink 4994376020 gfp_flags GFP_KERNEL cache items 93689873 delta 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 shrinker return val 46844928 There were huge deferred objects before the shrinker was called, the behavior 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 workloads are constrained by memcg which could limit the usage of kmem (by default now), so it seems maintaining deferred objects is not that useful anymore. It seems we could remove it to simplify the shrinker logic a lot. I may overlook some other important usecases of nr_deferred, comments are much appreciated.