linux-kernel - Re: [patch 00/27] [rfc] vfs scalability patchset

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: <20090428094821.GC9442@wotan.suse.de>
Date:	Tue, 28 Apr 2009 11:48:21 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 00/27] [rfc] vfs scalability patchset

On Tue, Apr 28, 2009 at 05:09:30AM -0400, Christoph Hellwig wrote:
> On Sat, Apr 25, 2009 at 09:06:49AM +0100, Al Viro wrote:
> > Maybe...  What Eric proposed is essentially a reuse of s_list for per-inode
> > list of struct file.  Presumably with something like i_lock for protection.
> > So that's not a conflict.
> 
> But what do we actually want it for?  Right now it's only used for
> ttys, which Nick has split out, and for remount r/o.  For the normal
> remount r/o case it will go away once we have proper per-sb writer
> counts.  And the fource remount r/o from sysrq is completely broken.
> 
> A while ago Peter had patches for files_lock scalability that went even
> further than Nicks, and if I remember the arguments correctly just
> splitting the lock wasn't really enough and he required additional
> batching because there just were too many lock roundtrips.  (Peter, do
> you remember the defails?)

Hmm, Peter's patch seemed like it was overkill to me. It avoids
the need for per-cpu files lists in the sb, but the cost is the
locked lists, the batching, etc. But even then it would still
generate more cacheline bounces because it needs to flush batches
back to the per-sb list.

Actually it should not be a problem to avoid the memory overhead
of my patch if we are willing to make the slowpath even slower.
Just have a global per-cpu list, and just test for sb equality
when walking the lists.

Anyway, I'll just continue to maintain this patch and if something
gets done with the file list first, then all the better.
--
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/