linux-kernel - Re: Inode Lock Scalability V4

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20101017025533.GA6482@amd>
Date:	Sun, 17 Oct 2010 13:55:33 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Dave Chinner <david@...morbit.com>
Cc:	Nick Piggin <npiggin@...nel.dk>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Inode Lock Scalability V4

On Sun, Oct 17, 2010 at 01:47:59PM +1100, Dave Chinner wrote:
> On Sun, Oct 17, 2010 at 04:55:15AM +1100, Nick Piggin wrote:
> > On Sat, Oct 16, 2010 at 07:13:54PM +1100, Dave Chinner wrote:
> > > This patch set is just the basic inode_lock breakup patches plus a
> > > few more simple changes to the inode code. It stops short of
> > > introducing RCU inode freeing because those changes are not
> > > completely baked yet.
> > 
> > It also doesn't contain per-zone locking and lrus, or scalability of
> > superblock list locking.
> 
> Sure - that's all explained in the description of what the series
> actually contains later on. 
> 
> > And while the rcu-walk path walking is not fully baked, it has been
> > reviewed by Linus and is in pretty good shape. So I prefer to utilise
> > RCU locking here too, seeing as we know it will go in.
> 
> I deliberately left out the RCU changes as we know that the version
> that is in your tree causes siginificant performance regressions for
> single threaded and some parallel workloads on small (<=8p)
> machines.

The worst-case microbenchmark is not a "significant performance
regression". It is a worst case demonstration. With the parallel
workloads, are you referring to your postmark xfs workload? It was
actually due to lazy LRU, IIRC. I didn't think RCU overhead was
noticable there actually.

Anyway, I've already gone over this couple of months ago when we
were discussing it. We know it could cause some small regressions,
if they are small it is considered acceptable and outweighed
greatly by fastpath speedup. And I have a design to do slab RCU
which can be used if regressions are large. Linus signed off on
this, in fact. Why weren't you debating it then?


>  There is more development needed there so, IMO, it has
> never been a candidate for this series which is aimed directly at
> .37 inclusion.


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