Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3229912pxj; Mon, 7 Jun 2021 05:47:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXBpQbKs4zhyqcDvW+lio6E452EjA3TbiC2KiGj04HCsveTkhXvn64oCzJOuHVfDd0zY6X X-Received: by 2002:aa7:c1da:: with SMTP id d26mr19725320edp.92.1623070065549; Mon, 07 Jun 2021 05:47:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623070065; cv=none; d=google.com; s=arc-20160816; b=rHjlEkJWTVJKZh4IdB4qj6b2b+bCfdKaSCSarNMIsm0LAkUXq4wlCYg/SlgO1g23Hn muL0aIPSbD9sCWwHLUyXqdseF0teIGsNr0+wAsDK3a3YBksVGzJY6iOgLDTxIFBxfEnC uC61qJzhAi7k4vqY3Ex/QpGCRUNtjHaq67M82fIe0YXLLkiJQIKhsf+KkYtvplQdPCC+ 3HrxFHCc5qfyeE69pEFu8ymEcYMQZjieUseE7UTz3A5MgbmTSYc7H3KGRza3WWpTFk/u RSdtr91NMGetTc1CNqXcgmso24H6aAxs65tidIkOeExeTaZHeL1hA0Dx8OsqSIpPusq9 2BYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:to :dkim-signature; bh=qc4IWWYqOFD9EILMCAJAVQis0JAtoX+TLAYYU9aqWwI=; b=BPRcPDMRz9MNAgykMMm4CsfIbHbWI7lEJzMHirO6UAeNS7EyYk6wSRISlkfY+33f/s L+PLJpd4TirArG+tITGaVoRWwnGBfqM/1XqQJAwMnH/EGy2gumy3lK5r+dPIpFCKP2Kh pMVF0ZuOVP760zE4T2jKMd9BPHx3l/2yvCTYS4ehpToGCHwrWHvIPcrp+92/bR/8A6rS F0TeRTRQJkzzwLmPVQp/O03bEKhszq6K5Cx1PF0Vt+Qx/RvblnBHotGf/ITFk0MivElN WToxN7SFwk0opJtqDzVmYuQHzvQ716byvcFxJhf1FFWPL9lv1CR/K16eO7D2ZUYvY6s7 V4iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pmhahn.de header.s=202002 header.b=IldtndQH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=pmhahn.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd11si12424964edb.528.2021.06.07.05.47.22; Mon, 07 Jun 2021 05:47:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@pmhahn.de header.s=202002 header.b=IldtndQH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=pmhahn.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230299AbhFGMsP (ORCPT + 99 others); Mon, 7 Jun 2021 08:48:15 -0400 Received: from birdy.pmhahn.de ([88.198.22.186]:43586 "EHLO birdy.pmhahn.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230269AbhFGMsN (ORCPT ); Mon, 7 Jun 2021 08:48:13 -0400 X-Greylist: delayed 403 seconds by postgrey-1.27 at vger.kernel.org; Mon, 07 Jun 2021 08:48:12 EDT Received: from [IPv6:2003:e2:7701:c200:a5ae:ca72:d4d5:6724] (p200300e27701C200A5aeca72D4D56724.dip0.t-ipconnect.de [IPv6:2003:e2:7701:c200:a5ae:ca72:d4d5:6724]) by birdy.pmhahn.de (Postfix) with ESMTPSA id DB9562207246; Mon, 7 Jun 2021 14:39:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pmhahn.de; s=202002; t=1623069575; bh=BBOoFi9HzmEh7B1OpgYxyXy8hseIid57bVC7FAkBMWE=; h=To:From:Subject:Date:From; b=IldtndQH66LqgCtd1zYeQWCI5owbGkaqz8YMfWxhDaLSL9HvYI8OxYSPuII/RAia5 YkTmp++EEFouXzNPMMlADn7E86uh3DgLlSl0rad9YToXrUPd0FbK2FrDlUwyfiJokr 5lq+i/KM2mEZR9X9JGPISmN6UJvWOs99fJpZwS+Vym0Z+BdHtcRjFJQ5YGnNTplBL/ R6KAbi+hpFei/a9uoV5GCYC7CfaKRoQ6zahgN+RvoZHEbMB6lkWk/TfSIfHL3XsVHl 0O4xZBMRRZ3lw2xy/0Jp/GXYFb/idwZdV908N1b6kxpikUS/ZOQLRfukW1NrLnyk8y m7o9ODcFlrwyg== To: "linux-kernel@vger.kernel.org" , "cgroups@vger.kernel.org" From: Philipp Hahn Subject: Prevent inode/dentry trashing? Message-ID: Date: Mon, 7 Jun 2021 14:39:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Similar to I would like to prevent certain programs from trashing the inode/dentry cache, which is a shared resource for all processes: - For example the nightly used to recursively walk the complete file system. As long as `d_name` and the `d_type` information from is enough this only pollutes the dentry cache. - Similar our backup software, but this also needs to each path to get the `mtime`, which additionally pollutes the inode cache. Both examples only walk the tree once (per day). In my case the caches do not fit into memory completely, so the second process does not even benefit from the first process filling the cache as that data is already replaced again. The trashed caches affect all other processes running in parallel or the first processes started each morning. Is it possible to prevent inode/dentry trashing for example by limiting the cache per process(-group)? Something like MADV_DONTNEED from for IO would be nice. An external knob to limit the cache usage per process(-group) would be nice, but even a hint for an API for such kind of programs to prevent trashing would help me. Thank you in advance. Philipp