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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F3BDC4332F for ; Wed, 23 Nov 2022 12:37:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A805B6B007D; Wed, 23 Nov 2022 07:37:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A32D36B007E; Wed, 23 Nov 2022 07:37:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D1A06B0080; Wed, 23 Nov 2022 07:37:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7E3356B007D for ; Wed, 23 Nov 2022 07:37:52 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 545ABC067E for ; Wed, 23 Nov 2022 12:37:52 +0000 (UTC) X-FDA: 80164658784.02.4D1CA7A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf23.hostedemail.com (Postfix) with ESMTP id DD5A3140009 for ; Wed, 23 Nov 2022 12:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669207071; 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: in-reply-to:in-reply-to:references:references; bh=YBG4FEs/FFeAepPw53/HoJSqPyKF5S2QkCZjLKqE5oY=; b=LwAAiO3CKQs+ZxeQaja9lKIc3RWAL8pv78Kip/y3y1nI7v+PfMHR51n5jxQf+yw/nPxB3e 0FUvJXho2TZQ2YkrtIag/pA2gdEL7utnHDfVjjrwEaGw1a7wWrJYupImAxdWmWj9dy+qw0 WbqcKFFay2qqk8cZzMrdhwThPvi0YPI= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-635-T6hj-cMpN-ycpUubqNiITA-1; Wed, 23 Nov 2022 07:37:50 -0500 X-MC-Unique: T6hj-cMpN-ycpUubqNiITA-1 Received: by mail-qk1-f199.google.com with SMTP id ay43-20020a05620a17ab00b006fa30ed61fdso22173622qkb.5 for ; Wed, 23 Nov 2022 04:37:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YBG4FEs/FFeAepPw53/HoJSqPyKF5S2QkCZjLKqE5oY=; b=xIB9EC/9Sjg6pONVcmZZnUyH7vNQZ+vfXbb5KyFxUwl7Sh7oazVf5bgs9VJ0BERy/E dYmHGbMxdg9NrVt2pRY6toSB7NO67YOJa2SvztokwQ2VHzLGk0pNRK/bQ7sk3U2oLP79 DxeMZR3S16XWQn/8cZAoVhlqcZ5zaKP1pK3UYbRJfGnSp51BhMmtFKqyCRDltiz6u1hs vscjYctQ4KL2Tk1C8I3Wc2CduwUzYi10O48itz76MerGuTJRyuito1kXDMAc2hh8Cjkw 8rdlgasA2SKZF7LecckGTzce8QEEPXz+NOQr4oTjQCBiIv163WBAED+MvTHcEmuAN6dQ 8mgQ== X-Gm-Message-State: ANoB5pnPWhRlurUU5yWWB2pXI//uH0xWy4oA8Y3HBI0wHdQRjZNCp+Qa z/WPjNgCSdOF9yTU/zU9e5gQKwLxGc5H3lE1JBeqtfjSWgG7Xs/B4EHTWL+UC00tmEYKGXGTz+r gpSJQeRhOv6M= X-Received: by 2002:ae9:e009:0:b0:6fb:c25:ddb8 with SMTP id m9-20020ae9e009000000b006fb0c25ddb8mr10786168qkk.377.1669207069757; Wed, 23 Nov 2022 04:37:49 -0800 (PST) X-Google-Smtp-Source: AA0mqf4U4uICC1jZlLMZk7rGxcGISEnwVgE1TruGHG4MPnRqNFZ0jFgPFSMtWL3rctn9YgpXw+bJAA== X-Received: by 2002:ae9:e009:0:b0:6fb:c25:ddb8 with SMTP id m9-20020ae9e009000000b006fb0c25ddb8mr10786146qkk.377.1669207069543; Wed, 23 Nov 2022 04:37:49 -0800 (PST) Received: from bfoster (c-24-61-119-116.hsd1.ma.comcast.net. [24.61.119.116]) by smtp.gmail.com with ESMTPSA id az42-20020a05620a172a00b006cfaee39ccesm12076404qkb.114.2022.11.23.04.37.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 04:37:49 -0800 (PST) Date: Wed, 23 Nov 2022 07:37:55 -0500 From: Brian Foster To: Lukas Czerner Cc: Christoph Hellwig , "Darrick J. Wong" , Hugh Dickins , Jan Kara , Eric Sandeen , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 1/3] quota: add quota in-memory format support Message-ID: References: <20221121142854.91109-1-lczerner@redhat.com> <20221121142854.91109-2-lczerner@redhat.com> <20221122142117.epplqsm4ngwx5eyy@fedora> <20221123083615.sj26ptongwhk6wcl@fedora> MIME-Version: 1.0 In-Reply-To: <20221123083615.sj26ptongwhk6wcl@fedora> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669207071; a=rsa-sha256; cv=none; b=y8Q+Qgm8QPwE2EyUx/48x67V7JYz+bKBZvbZ4xqUsi/DoAev+pKdK84D15atDaUZKcWf82 rFXMpZqqzXZ9fsfDNU4GUzeTz0usohQRYkqo84+kcyNxrnf2E9Legv033wj8De7WVU/ztO yTstEYNtifd5NP9KIOvRQpAlVDxNZq4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LwAAiO3C; spf=pass (imf23.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669207071; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YBG4FEs/FFeAepPw53/HoJSqPyKF5S2QkCZjLKqE5oY=; b=Fs7btrSkF6t3tymb5xSH7MfwaAgCJIpN5CE0fxGbgiTERZESsisREeoXxZ1r1rwlccD4bY vHbmsFiqvRPP06CnDzMfU2Q8fEA3SH4pzyz/MhwT2bqLb9yxVFMvwK3Kpdc0CpY+onrSf/ bJ4QMRhm3WETZKxeQ+nYsk+c0lSdQW4= X-Rspam-User: X-Rspamd-Queue-Id: DD5A3140009 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LwAAiO3C; spf=pass (imf23.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: 57j48k9n6m7744cbjor34gm59hpm8aap X-Rspamd-Server: rspam10 X-HE-Tag: 1669207071-485968 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 Wed, Nov 23, 2022 at 09:36:15AM +0100, Lukas Czerner wrote: > On Tue, Nov 22, 2022 at 11:58:33PM -0800, Christoph Hellwig wrote: > > On Tue, Nov 22, 2022 at 03:21:17PM +0100, Lukas Czerner wrote: > > > > That seems like a good idea for memory usage, but I think this might > > > > also make the code much simpler, as that just requires fairly trivial > > > > quota_read and quota_write methods in the shmem code instead of new > > > > support for an in-memory quota file. > > > > > > You mean like the implementation in the v1 ? > > > > Having now found it: yes. > > > > Jan, > > do you have any argument for this, since it was your suggestion? > > I also think that the implementation is much simpler with in-memory > dquots because we will avoid all the hassle with creating and > maintaining quota file in a proper format. It's not just reads and > writes it's the entire machinery befind it in quota_v2.c and quota_tree.c. > > But it is true that even with only user modified dquots being > non-reclaimable until unmount it could theoreticaly represent a > substantial memory consumption. Although I do wonder if this problem > is even real. How many user/group ids would you expect extremely heavy > quota user would have the limits set for? 1k, 10k, million, or even > more? Do you know? > I don't know this code well enough to have a strong opinion on the v1 vs. v2 approach in general, but FWIW it does seem to me that the benefit of v1 from a memory savings perspective is perhaps overstated. AFAICT, tmpfs already pins inodes/denties (notably larger than dquots) in-core for the lifetime of the inode, so it's not like we'll be saving much memory from dquots that are actually in-use. I think this dquot memory should be limited indirectly by the max inode restriction, as well. That means the potential wastage is measured in dquots that are no longer referenced, but have previously had a non-default quota limit set by the admin, right? Even with the v1 approach, I don't think it's wise to just push such otherwise unused dquots into swap space indefinitely. Perhaps a reasonable approach to the memory usage issue is to just cap the number of dquots that are allowed to have custom limits on tmpfs? E.g., to echo Lukas above.. if there was a cap of something like 512-1k custom quota limits, would that really be a problem for quota users on tmpfs? Other users would still be covered by the default mount-time limits. Of course, you could always make such a cap flexible as a % of tmpfs size, or configurable via mount option, etc. Just a thought. Brian > -Lukas > >