linux-kernel - Re: [PATCH 17/18] fs: icache remove inode

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]

Date:	Wed, 13 Oct 2010 18:27:01 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Dave Chinner <david@...morbit.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/18] fs: icache remove inode_lock

On Wed, Oct 13, 2010 at 06:20:58PM +1100, Nick Piggin wrote:
> On Fri, Oct 08, 2010 at 04:21:31PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@...hat.com>
> > 
> > All the functionality that the inode_lock protected has now been
> > wrapped up in new independent locks and/or functionality. Hence the
> > inode_lock does not serve a purpose any longer and hence can now be
> > removed.
> > 
> > Based on work originally done by Nick Piggin.
> 
> Sorry about being offline for so long. I had some work finishing with
> SUSE and then took some vacation without much net access for several
> weeks :P
> 
> Unfortunate timing that everybody is suddenly interested in the
> scalability work :) I didn't want to dump a lot of patches just
> before I went and not be able to support them if they were merged /
> respond to review in a timely way. But I still want to maintain my
> vfs-scale stack. I'm glad to see lots of interest in it now.
> 
> So I will like criticism of that and hopefully fold improvements back.
> The problem I guess with taking the patches and reworking them a bit is
> just that I have lost a bit of context of what you're doing, and also
> it loses it's verification within the entire series (ie. the end goal
> of doing store free path walking relies a bit on RCU inode for example),
> and I've done a lot of microbenchmarking.

I guess my point here is not that the inode scaling series must be
set in stone or that I'm not happy to debate changes. But what I would
like is to have that series working within the full vfs-scale branch
before merging pices of it.

This is basically because there are some dependencies with the rcu walk,
for example, and also the need to measure the end-game performance of
the whole series and ensure that there are no showstopper regressions or
nasty surprises.

I'm happy to help to port the top of the patch set onto changes in
earlier parts of it, but I would like the chance to do this really. I'm
back in action now, so I can spend a lot of time catching up.

As I said, I'll continue catching up with all the threads and see where
it's up to.

Thanks,
Nick


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