linux-kernel - [rfc] scale dcache locking

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-next>] [day] [month] [year] [list]

Message-Id: <20090329155539.275927173@nick.local0.net>
Date:	Mon, 30 Mar 2009 02:55:39 +1100
From:	npiggin@...e.de
To:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [rfc] scale dcache locking

This is my sketch for improving dcache locking scalability. So far I've
only really been looking at core code to get an idea of how it might look,
so most configurable functionality is broken (and unfortunately it might
well be something in there which will cause a fundamental problem for me).

But there is a *lot* of stuff to go through, so I like to just get some
early opinions of this.

I have tried to split it as nicely as possible. Patch splitting still
needs a bit more work, but it is not too bad hopefully to review.

It seems to break naturally into 3 phases:
- First phase is to add new locks and rules to protect specific data
  structures and dentry fields. This attempts to be as simple and dumb
  replacement as possible, to make review easier.

- Second phase is to remove dcache_lock after it is not protecting
  anything itself.

- Last phase is to improve existing locking schemes, and improve the
  scalability of the newly added locks.

It's nowhere near complete, but it is running and relatively stable
on configs where it compiles. As far as core locking changes go for
this project, I still need to make nr_dentry into a per-cpu counter,
and break up the LRU lock (which is the last remaining global lock
broken out of dcache_lock). LRU lock currently naturally splits into
per-sb locking, but that's not satisfying because we also want really
good scalability within a single sb. I think per-memory-zone LRU lists
and locking might be a good idea because it scales with socket count
and also makes better NUMA targetted dcache reclaim possible. Making
LRU more lazy might also be a good idea to reduce locking.

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