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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_1 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 1C77CC433FE for ; Sun, 13 Dec 2020 18:52:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 90C5322582 for ; Sun, 13 Dec 2020 18:52:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90C5322582 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B74786B0036; Sun, 13 Dec 2020 13:52:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AFD8A6B005C; Sun, 13 Dec 2020 13:52:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C5826B005D; Sun, 13 Dec 2020 13:52:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 839506B0036 for ; Sun, 13 Dec 2020 13:52:08 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5200F180AD82F for ; Sun, 13 Dec 2020 18:52:08 +0000 (UTC) X-FDA: 77589153936.09.noise12_6114d4327414 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 2537D180ACF75 for ; Sun, 13 Dec 2020 18:52:08 +0000 (UTC) X-HE-Tag: noise12_6114d4327414 X-Filterd-Recvd-Size: 5837 Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Sun, 13 Dec 2020 18:52:07 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BDInnv5095008; Sun, 13 Dec 2020 18:52:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=m+agSRCv2C7vA1smCTi9nr9ItANyGc4Iz5+EOO7ykN8=; b=CjylZuqN6lVabLCFgLdzeaUdMmE3xSDWWJXAUzymzlsZoiR8Uggp2G2dekEfTWR61N28 23zeynROsAP/N9YlLT84VY7IO/NnFh0vyZxx8Om6KsS4HtSKjdkkxPRxKUfw7xZGMOYP gIzWg5iVPBF+ctewxhnCj616R4St2fK4mmQJSdzYGyoYfCWnoxGj5s/H9tVtsvO6yL+B 1kr0CSLGGJa7nls4iZrmXO2EPRkxvs6M1OfAHgwIIbRzGw6kFHBZOfsaKL9tG4zG2T7I pzzEcV8OWET8Jy9mx2/3BdQuaf+7M1ljYZGQSV3s3Tk9/0ZqZrRbk1a+GQlhZSMIsIHu 3Q== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 35cntktnan-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 13 Dec 2020 18:52:05 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BDIf3Rd045988; Sun, 13 Dec 2020 18:50:04 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 35d7ejqw4q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Dec 2020 18:50:04 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BDIo3tt021888; Sun, 13 Dec 2020 18:50:03 GMT Received: from Junxiaos-MacBook-Pro.local (/73.231.9.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Dec 2020 10:50:02 -0800 Subject: Re: [PATCH RFC 0/8] dcache: increase poison resistance To: Konstantin Khlebnikov Cc: Konstantin Khlebnikov , Linux Kernel Mailing List , linux-fsdevel , linux-mm@kvack.org, Alexander Viro , Waiman Long , Gautham Ananthakrishna , matthew.wilcox@oracle.com References: <158893941613.200862.4094521350329937435.stgit@buzz> <97ece625-2799-7ae6-28b5-73c52c7c497b@oracle.com> From: Junxiao Bi Message-ID: Date: Sun, 13 Dec 2020 10:49:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9834 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012130147 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9834 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 impostorscore=0 priorityscore=1501 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012130148 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 12/11/20 11:32 PM, Konstantin Khlebnikov wrote: > On Thu, Dec 10, 2020 at 2:01 AM Junxiao Bi > wrote: > > Hi Konstantin, > > We tested this patch set recently and found it limiting negative > dentry > to a small part of total memory. And also we don't see any > performance > regression on it. Do you have any plan to integrate it into > mainline? It > will help a lot on memory fragmentation issue causing by dentry slab, > there were a lot of customer cases where sys% was very high since > most > cpu were doing memory compaction, dentry slab was taking too much > memory > and nearly all dentry there were negative. > > > Right now I don't have any plans for this. I suspect such problems will > appear much more often since machines are getting bigger. > So, somebody will take care of it. We already had a lot of customer cases. It made no sense to leave so many negative dentry in the system, it caused memory fragmentation and not much benefit. > > First part which collects negative dentries at the end list of > siblings could be > done in a more obvious way by splitting the list in two. > But this touches much more code. That would add new field to dentry? > > Last patch isn't very rigid but does non-trivial changes. > Probably it's better to call some garbage collector thingy periodically. > Lru list needs pressure to age and reorder entries properly. Swap the negative dentry to the head of hash list when it get accessed? Extra ones can be easily trimmed when swapping, using GC is to reduce perf impact? Thanks, Junxioao. > > Gc could be off by default or thresholds set very high (50% of ram for > example). > Final setup could be left up to owners of large systems, which needs > fine tuning.