linux-kernel - Re: [patch 00/28] [rfc] dcache scaling part 1

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: <877hgcrzgd.fsf@basil.nowhere.org>
Date:	Wed, 17 Nov 2010 11:56:02 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/28] [rfc] dcache scaling part 1

Nick Piggin <npiggin@...nel.dk> writes:

> There are 3 main parts to dcache scaling. This one primarily adds new locks
> to take over dcache_lock, and some pre/post prep and streamlining patches.
>
> The second implements fine grained locking, and is rather trivial after
> part 1.
>
> The third implements rcu-walk. rcu-walk depends on the first part, because it
> relies on using d_lock to protect the state of the dentry (when converting from
> rcu-walk to refcounted walk). Without the fine grained locing, we'd need to use
> dcache_lock for that, which would be a step backwards to put into path walking
> again.
>
> Comments?

I read 15, 10, 8, 5, 4, 3, 1 so far (weird order, it showed that way in
my reader :-) There was nothing surprising in any of those and they all
seem to do what the description advertises.

I was scared a bit by the upto 4 level dcache lock nestings, but I
assume those will get better again when everything is done.
At least from a quick look they seem to be all in the right order
(I assume you attempted some runtime coverage with lockdep too, right?)

For some of the hash lists it may become attractive to consider
the newly posted lockless list, but it wasn't fully clear
if that was easy to do (the lock protected a bit more than
just the list node)

For the level file system tree sweep changes it would be nice
if there were semantic patches available. That would make
it easier to verify the changes have been consistently
done, by rerunning the patcher.

You can add a Reviewed-by: Andi Kleen <ak@...ux.intel.com>
to the patches listed above.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/