Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20231011213919.52267-1-sconnor@purestorage.com> <ZShUmLU3X5QMiWQH@google.com>
In-Reply-To: <ZShUmLU3X5QMiWQH@google.com>
From:   Seamus Connor <sconnor@purestorage.com>
Date:   Thu, 12 Oct 2023 16:59:34 -0700
Message-ID: <CAB5MrP5VqmWpnS9O6vQpFWp254rpu6rx9Ki85fKZDUBb586WOQ@mail.gmail.com>
Subject: Re: [PATCH] [WIP] configfs: improve item creation performance
To:     Seamus Connor <sconnor@purestorage.com>,
        Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

>
> This is subtle.  Your patch description of course describes why we are
> partitioning the items and attributes, but that will get lost into the
> memory hole very quickly.  Please add a comment.
>

Will do. And thanks for taking a look at the patch.

> Plus, aren't the pinned/not-pinned checks redundant?  Can't we avoid the
> extra conditional?
>
>
> ```
>         spin_lock(&configfs_dirent_lock);
>         list_for_each_entry(sd, &parent_sd->s_children, s_sibling) {
> -               if ((sd->s_type & CONFIGFS_NOT_PINNED) &&
> -                   !strcmp(configfs_get_name(sd), dentry->d_name.name)) {

Unfortunately they are not. CONFIGFS_IS_PINNED and CONFIGFS_NOT_PINNED
are asymmetrical. There is the readdir cursor (s_type == 0) that might
be anywhere in the list and should not be treated as a pinned item,
but should also not be treated as an unpinned attribute.

Is there any testing that you could recommend for this change? So far
I've gone through testing of our internal components that depend on
configfs, but I haven't done anything targeted.

Thanks,
Seamus