Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp386832pxb; Tue, 19 Oct 2021 05:05:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBgd02v2x+DBC7HM75e7wq8wOOxOueUL2IDV2KmdXhstdyUMebWb2E+xMScXtMmeLezKzw X-Received: by 2002:a17:90a:bd08:: with SMTP id y8mr6042157pjr.123.1634645111828; Tue, 19 Oct 2021 05:05:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634645111; cv=none; d=google.com; s=arc-20160816; b=eTSVaTxf1uWuerJ59PCemNvdyUFDl5MsjsqjzC7pFcPDVJwhiiz76JO/DHOKs6ui+R rhck3isWG9NLd2VslvswjSTas6//C+W3+C08h5RLL8GpMWfCyd9jxUfHdy81C393Oc8I gARFQnft5y2h+gB8CgqpJ0PnIBIXmqiqEJItJvw44SlAt1ilCUtmbv/FAIJZ9kfZWdVB 7TXQQ4PTUe/6v4HpPVwZRomMuO8TcLvGFMGPNtctv9OzshUtjFoUWKCga5nmsKv6q5os yEc/0ySPW4wYQXieXApboLbZIl5z19XGw1R0Ct3MkiHYoVgMfbVJiBw3XZfYd4dObnb0 wZiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=AOx0YP1UeYYzT4mYlA9g3w+LktMDzaz68AOx+gTw7qw=; b=ZM7jQV3LYcuzJqYndbj9CGqaG3xraWFUQIDmGx0VCeVpLYtprNEj2gtSzJ2a7tF8rK Xg5Ya4lHdgZcJZCtEZs1Y9AysgMf0yuaTtWoe+LrupesUFIZ0HHGkZgcObfgpjW2LZlf Yo/edV26ZwfWCMZvHHMeCdpzptbAWNehenuhLuj84kI7l5hfs74h0b+og4YQO5Giv6Sn GUrfGPuW/7jMCcxGlPnfnW0XlDQKkKDcw5RdBFsQPwTpSPIPxevLUmmAHg71KUjz+nkp nQp0OIYIWAvEYXv4fmztWD1L/Acj4Roy8Z3rE2b6oUSLgK0T0BLG4uWFlHu3ZtD6a6gL /PEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Al9IiWid; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mr1si3107985pjb.118.2021.10.19.05.04.53; Tue, 19 Oct 2021 05:05:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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=@suse.cz header.s=susede2_rsa header.b=Al9IiWid; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230097AbhJSMFe (ORCPT + 99 others); Tue, 19 Oct 2021 08:05:34 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:45804 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235431AbhJSMFd (ORCPT ); Tue, 19 Oct 2021 08:05:33 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CCFA91FD2D; Tue, 19 Oct 2021 12:03:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1634644999; h=from:from:reply-to: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=AOx0YP1UeYYzT4mYlA9g3w+LktMDzaz68AOx+gTw7qw=; b=Al9IiWidJ4t78Vu1mCC9HkCEVzoWENJ2ZN4dhIL0wdB7EGKNzjhvYGeSYTeaWDyUv9lIie 25BPUi0XQH4fTtkKt1H8gK2FLJ1FRdRMJD0UFnVA/+DXPqe+QcKKFUJwaPKVfKcPpqdcrM cF+qAmWgTVuqHx0tLnPNNlXLGyiMIl4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1634644999; h=from:from:reply-to: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=AOx0YP1UeYYzT4mYlA9g3w+LktMDzaz68AOx+gTw7qw=; b=u1TPYVZyLyWZr3mebAn/kNtq5LptGoPutV5Age3+pxvEvAJmXG0/LrGDG4l3F130YrEPRx vJnj+OoLL63c0zBw== Received: from quack2.suse.cz (unknown [10.100.200.198]) by relay2.suse.de (Postfix) with ESMTP id B7C0EA3B9A; Tue, 19 Oct 2021 12:03:19 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 953751E0983; Tue, 19 Oct 2021 14:03:16 +0200 (CEST) Date: Tue, 19 Oct 2021 14:03:16 +0200 From: Jan Kara To: Amir Goldstein Cc: Gabriel Krisman Bertazi , Jan Kara , "Darrick J. Wong" , Theodore Tso , Dave Chinner , David Howells , Khazhismel Kumykov , linux-fsdevel , Ext4 , Linux API , kernel@collabora.com Subject: Re: [PATCH v8 20/32] fanotify: Dynamically resize the FAN_FS_ERROR pool Message-ID: <20211019120316.GI3255@quack2.suse.cz> References: <20211019000015.1666608-1-krisman@collabora.com> <20211019000015.1666608-21-krisman@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 19-10-21 08:50:23, Amir Goldstein wrote: > On Tue, Oct 19, 2021 at 3:03 AM Gabriel Krisman Bertazi > wrote: > > > > Allow the FAN_FS_ERROR group mempool to grow up to an upper limit > > dynamically, instead of starting already at the limit. This doesn't > > bother resizing on mark removal, but next time a mark is added, the slot > > will be either reused or resized. Also, if several marks are being > > removed at once, most likely the group is going away anyway. > > > > Signed-off-by: Gabriel Krisman Bertazi > > --- > > fs/notify/fanotify/fanotify_user.c | 26 +++++++++++++++++++++----- > > include/linux/fsnotify_backend.h | 1 + > > 2 files changed, 22 insertions(+), 5 deletions(-) > > > > diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c > > index f77581c5b97f..a860c286e885 100644 > > --- a/fs/notify/fanotify/fanotify_user.c > > +++ b/fs/notify/fanotify/fanotify_user.c > > @@ -959,6 +959,10 @@ static int fanotify_remove_mark(struct fsnotify_group *group, > > > > removed = fanotify_mark_remove_from_mask(fsn_mark, mask, flags, > > umask, &destroy_mark); > > + > > + if (removed & FAN_FS_ERROR) > > + group->fanotify_data.error_event_marks--; > > + > > if (removed & fsnotify_conn_mask(fsn_mark->connector)) > > fsnotify_recalc_mask(fsn_mark->connector); > > if (destroy_mark) > > @@ -1057,12 +1061,24 @@ static struct fsnotify_mark *fanotify_add_new_mark(struct fsnotify_group *group, > > > > static int fanotify_group_init_error_pool(struct fsnotify_group *group) > > { > > - if (mempool_initialized(&group->fanotify_data.error_events_pool)) > > - return 0; > > + int ret; > > + > > + if (group->fanotify_data.error_event_marks >= > > + FANOTIFY_DEFAULT_MAX_FEE_POOL) > > + return -ENOMEM; > > > > - return mempool_init_kmalloc_pool(&group->fanotify_data.error_events_pool, > > - FANOTIFY_DEFAULT_MAX_FEE_POOL, > > - sizeof(struct fanotify_error_event)); > > + if (!mempool_initialized(&group->fanotify_data.error_events_pool)) > > + ret = mempool_init_kmalloc_pool( > > + &group->fanotify_data.error_events_pool, > > + 1, sizeof(struct fanotify_error_event)); > > + else > > + ret = mempool_resize(&group->fanotify_data.error_events_pool, > > + group->fanotify_data.error_event_marks + 1); > > + > > + if (!ret) > > + group->fanotify_data.error_event_marks++; > > + > > + return ret; > > } > > This is not what I had in mind. > I was thinking start with ~32 and double each time limit is reached. Do you mean when number of FS_ERROR marks reaches the number of preallocated events? We could do that but note that due to mempool implementation limits there cannot be more than 255 preallocated events, also mempool_resize() will only update number of slots for preallocated events but these slots will be empty. You have to manually allocate and free events to fill these slots with preallocated events. > And also, this code grows the pool to infinity with add/remove mark loop. I see a cap at FANOTIFY_DEFAULT_MAX_FEE_POOL in the code there. But I don't think there's a good enough reason to hard-limit number of FS_ERROR marks at 128. As I explained in the previous version of the series, in vast majority of cases we will not use even a single preallocated event... > Anyway, since I clearly did not understand how mempool works and > Jan had some different ideas I would leave it to Jan to explain > how he wants the mempool init limit and resize to be implemented. Honestly, I'm for keeping it simple for now. Just 32 preallocated events and try to come up with something more clever only if someone actually complains. Honza -- Jan Kara SUSE Labs, CR