linux-kernel - Re: [PATCH 02/17] fs: icache lock s

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: <20101017004257.GA1614@infradead.org>
Date:	Sat, 16 Oct 2010 20:42:57 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/17] fs: icache lock s_inodes list

On Sun, Oct 17, 2010 at 04:09:11AM +1100, Nick Piggin wrote:
> If you want it to be scalable within a single sb, it needs to be
> per cpu. If it is per-cpu it does not need to be per-sb as well
> which just adds bloat.

Right now the patches split up the inode lock and do not add
per-cpu magic.  It's not any more work to move from per-sb lists
to per-cpu locking if we eventually do it than moving from global
to per-cpu.

I'm not entirely convinced moving s_inodes to a per-cpu list is a good
idea.  For now per-sb is just fine for disk filesystems as they have
much more fs-wide cachelines they touch for inode creatation/deletion
anyway, and for sockets/pipes a variant of your patch to not ever
add them to s_inodes sounds like the better approach.

If we eventually hit the limit for disk filesystems I have some better
ideas to solve this.  One is to abuse whatever data sturcture we use
for the inode hash also for iterating over all inodes - we only
iterate over them in very few places, and none of them is a fast path.

--
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/