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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 0D538C433DB for ; Thu, 24 Dec 2020 11:13:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A57C208A9 for ; Thu, 24 Dec 2020 11:13:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A57C208A9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=natalenko.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8050E8D0075; Thu, 24 Dec 2020 06:13:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B4A18D0061; Thu, 24 Dec 2020 06:13:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C99B8D0075; Thu, 24 Dec 2020 06:13:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id 525768D0061 for ; Thu, 24 Dec 2020 06:13:37 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 95064362E for ; Thu, 24 Dec 2020 11:13:36 +0000 (UTC) X-FDA: 77627915232.24.goose17_380193227470 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 7AAF71A4A5 for ; Thu, 24 Dec 2020 11:13:36 +0000 (UTC) X-HE-Tag: goose17_380193227470 X-Filterd-Recvd-Size: 2623 Received: from vulcan.natalenko.name (vulcan.natalenko.name [104.207.131.136]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Dec 2020 11:13:35 +0000 (UTC) Received: from localhost (home.natalenko.name [151.237.229.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by vulcan.natalenko.name (Postfix) with ESMTPSA id D7AD18F90CF; Thu, 24 Dec 2020 12:13:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=dkim-20170712; t=1608808408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=gU2GHX8ErPj4WjP6+ZyvbnUEfSR5V0an6n9r08YKmTI=; b=GlVlOf7zNLC6z0NZkpy/jvc683cBEzTUPITSuQnHFVZjRiKmij5x9Fb9umr/+NzCNXr1+v yCc4XHFduiZ9/q78BvpYfatQ0xS2og6pff9RIAl6PUpFMzrG5qBRejqi0h6PwZ8aGLKQem 2t2pKl00Ab9liNtso+RIxzTymTZLWmc= Date: Thu, 24 Dec 2020 12:13:27 +0100 From: Oleksandr Natalenko To: linux-kernel@vger.kernel.org Cc: Mandeep Singh Baines , Guenter Roeck , Andrew Morton , linux-mm@kvack.org Subject: min_filelist_kbytes vs file_is_tiny Message-ID: <20201224111327.knhqdz3hloxfcksv@spock.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Hello, Mandeep, Guenter et al. I came across the out-of-tree patch [1] that apparently is still alive after 10 years of residing in the Chromium OS tree, and I have a couple of questions if you don't mind spending your time answering them. 1. is this knob really necessary given there's an explicit bailout mechanism relying on `file_is_tiny` which depends on the sum of high watermarks across the zones? Wouldn't increasing `vm.min_free_kbytes` achieve basically the same? 2. if `vm.min_free_kbytes` is not an option, would setting `file_is_tiny` based on your `min_filelist_kbytes` knob achieve the same? 3. if not, is `memory.min` cgroup2 knob supposed to work in a similar manner? it looks to be unavailable for the root cgroup, though. What I'm looking for, basically, is to achieve the effect of the mentioned patch using mechanisms that are already available in the upstream kernel. Thank you. [1] https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/545e2917dbd863760a51379de8c26631e667c563^!/ -- Oleksandr Natalenko (post-factum)