linux-kernel - Re: [PATCH 12/17] fs: Introduce per-bucket inode hash locks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100930015213.GA1535@infradead.org>
Date:	Wed, 29 Sep 2010 21:52:14 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 12/17] fs: Introduce per-bucket inode hash locks

Instead of doing the lock overkill on a still fundamentally global data
structure what about replacing this with something better.  I know
you've already done this with the XFS icache, and while the per-AG
concept obviously can't be generic at least some of the lessons could be
applied.

then again how much testing did this get anyway given that you
benchmark ran mostly XFS which doesn't hit this at all?

If it was up to me I'd dtop this (and the bl_list addition) from the
series for now and wait for people who care about the scalability of
the generic icache code to come up with a better data structure.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/