LWN: Comments on "The lockless page cache"

The lockless page cache

helltone — Fri, 12 Jun 2009 12:24:02 +0000

Can you please explain the difference between lock-free and lockless? That's a complex topic, and I can't find anything on that... e-mail me a link if you have a good reference please: gafunchal AT gmail DOT com

Performance booster ?

RTT — Wed, 15 Oct 2008 05:50:02 +0000

What if instead there were multiple page files for each core.

And plus, what if each of those page file is on a separate SAS hard disk ?

The lockless page cache

Nick — Sun, 03 Aug 2008 00:00:47 +0000

I would be surprised if there was anything too noticeable for desktop types of workloads,
however 
the nice thing about these patches is that they actually speed up single threaded performance
as 
well as improve scalability.

Here is my justification to have them merged, which includes some numbers:
http://lwn.net/Articles/285339/

For server workloads using threads and direct IO, there should be some improvement at even 2
or 4 
cores. The OLTP database workload that gained nearly 10% throughput was run on a 2s/8c system,

so a 4 core system should see a few %.

lockless data structures?

PaulMcKenney — Fri, 01 Aug 2008 15:42:21 +0000

Val's comment is directed at lock-free synchronization, which is a very different animal than lockless algorithms. The RCU implementation described in this article is lockless, but not lock-free: although RCU has deterministic read-side primitives, its updates can block via call_rcu() and synchronize_rcu(). In some cases, the fact that RCU's updates do block keeps things (relatively) simple.

We are still learning how best to use RCU to obtain good performance and scalability while keeping things (again, relatively) simple. For that matter, we are also still learning when not to use RCU. RCU is quite specialized, so is not always the right tool for the job, much though I might wish it otherwise. ;-)

Linus on lockless data structures

pflugstad — Fri, 01 Aug 2008 14:01:57 +0000

Linus posts in a long thread over on RealWorldTech about lockless algorithms and SMP scaling:

http://www.realworldtech.com/forums/index.cfm?action=deta...

lockless data structures?

maney — Fri, 01 Aug 2008 01:43:17 +0000

From one of Val's responses to a question asked about the KHB: Synthesis article:

My personal opinion is that lock-free algorithms are not a good generic synchronization technique, and are definitely very very complex and difficult to understand. However, in certain specific cases, lock-free can be simple, elegant, and a huge performance advantage over traditional approaches.

lockless data structures?

bronson — Thu, 31 Jul 2008 21:38:16 +0000

Yes.  Lockless is quite simple in theory but gets really difficult in the real world (say,
where ring buffers actually wrap).  You thought threading was hard to prove correct, debug,
and maintain?  Lockless is harder in every way.

I converted a small event-based networking app I wrote two years ago to use lockless lists.
It was fun but ultimately a waste of time...  It didn't run much faster but now it contained
subtle boundary conditions that, when violated by an unwary programmer, resulted in occasional
corruptions under load.  Good luck trying to debug that (don't bother stepping through it in
gdb)!

There are a few areas where lockless really is worth it, especially when you have a hot,
high-contention buffer or stack.  But be prepared for some tough maintenance.

lockless data structures?

shapr — Thu, 31 Jul 2008 20:02:00 +0000

Is there a good reason linux doesn't have lots of lockless data structures all over the place?
That would dramatically increase multi-core performance, yeah?

The lockless page cache

nix — Thu, 31 Jul 2008 15:51:51 +0000

Code isn't really tricky unless it has at least one 'QUA'ing koala in it.

;}

The lockless page cache

intgr — Thu, 31 Jul 2008 15:31:01 +0000

Do these changes have a measurable speed gain with practical workloads on dual-core or
quad-core processors? The only benchmark I found was a synthetic benchmark from April 2006 by
Jens Axboe. The patch has probably been turned inside out since then.