Received-SPF: pass (google.com: domain of linux-kernel+bounces-79993-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Sun, 25 Feb 2024 01:38:15 -0500
From: Al Viro <viro@kernel.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-kernel@vger.kernel.org, Thomas Graf <tgraf@suug.ch>,
	Herbert Xu <herbert@gondor.apana.org.au>, netdev@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, maple-tree@lists.infradead.org,
	rcu@vger.kernel.org
Subject: Re: [PATCH 1/1] rosebush: Add new data structure
Message-ID: <ZdrgV8GUE92HMojn@duke.home>
References: <20240222203726.1101861-1-willy@infradead.org>
 <20240222203726.1101861-2-willy@infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240222203726.1101861-2-willy@infradead.org>

On Thu, Feb 22, 2024 at 08:37:24PM +0000, Matthew Wilcox (Oracle) wrote:
> Rosebush is a resizing hash table.  See
> Docuemntation/core-api/rosebush.rst for details.

Interesting...  A few obvious questions wrt dcache:
	* how do the locks that stuff nest wrt ->d_lock?  Inside?
	* same for rename_lock (on rename dentries change names/parents/hash
values).
	* we would be really forced to maintain DCACHE_UNHASHED in ->d_flags;
it's not impossible to do, but will take care (protection of ->d_flags has
several dark corners).
	* the cost of d_drop() goes up.  Might or might not get painful.
	* if the bucket locks nest inside ->d_lock, we'd better look out
for the latter getting held for longer.  Might get unpleasant.