mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Joel Fernandes <joelagnelf@nvidia.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	linux-kernel@vger.kernel.org, Boqun Feng <boqun@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	Christian Brauner <brauner@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Andrew Ballance <andrewjballance@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
	rcu@vger.kernel.org
Subject: Re: [RFC PATCH 00/12] RCU pseudo-transactions
Date: Fri, 23 Oct 2026 09:37:39 -0400	[thread overview]
Message-ID: <7f1e23a9-7d42-4a50-98d0-c932a2db4b8e@efficios.com> (raw)
In-Reply-To: <20261019005556.GA997610@joelbox>

On 2026-10-18 20:55, Joel Fernandes wrote:
> On Fri, Oct 16, 2026 at 09:33:07AM -0400, Mathieu Desnoyers wrote:
>> Hi,
>>
>> Earlier this year, I came up with a neat trick which reduces the mental
>> challenge of adapting data structures to RCU.  It turns out that it also
>> widens the applicability of RCU to additional classes of data
>> structures.
>>
>> This is done by a low-overhead abstraction which I'm naming
>> "RCU Pseudo-Transactions" [1, 2]. I name this "pseudo" because unlike
>> classic transactions, the writers exclude each other, readers get no
>> snapshot, and there is no abort.
> 
> Cool idea! Instead of tagging the pointer, perhaps alternatively the proxy
> object can be allocated in specific dedicated parts of kernel address space?
> Might be slower to test against though. But perhaps will make it usable by any
> users who use lower bits for other purposes.

A range check is possible, but it costs more on the read-side fast
path than a single-bit test, and with variable bounds it adds memory
loads. On x86-64, roughly:

1) Low-bit tag:              ptr & 0x1

      test  $0x1, %al
      jnz   slow

2) Range, constant bounds:   ptr >= BEGIN && ptr < END

      sub   $BEGIN, %rax
      cmp   $(END - BEGIN), %rax
      jb    slow

3) Range, variable bounds:   ptr >= begin && ptr < end

      cmp   begin(%rip), %rax
      jb    fast
      cmp   end(%rip), %rax
      jb    slow

Users that already need a low bit for other purposes can align their
objects on 16 bytes and use any of the other low bits as the tag,
still with a single test. A multi-bit pattern within the low 4 bits
can also be used as the tag, at the cost of and + cmp + jne on the
fast path, if more flexibility is needed.

One alternative I've considered (suggested by Paul McKenney) was to
use a trap (page fault) to handle the proxy case. The idea would be to
make sure the proxy address range triggers a read fault, and handle
the proxy resolution within a page fault handler.

This is a tradeoff: we'd skip the test-and-branch on the fast path,
but we would then have to make readers take page faults (orders of
magnitude slower) whenever they run concurrently with an ongoing
transaction. This would favor a workload with very infrequent updates
at a large cost for workloads where updates are not *so* infrequent.

Therefore I went for an approach which would keep read-side overhead in
the same order of magnitude whether or not a transaction is in progress,
hence the low-bit tag check.

> Btw, Pseudo-Transactions sounds long and weird, maybe "RCU proxy"? :-)

I initially called it "RCU flip-latch proxy", but ended up going for
a name that better describes what this really is: a transaction
in the filesystem (journaling) sense.

Note that I use "proxy" in my definitions and code to describe pointers
that are re-routed to the transaction descriptor records.

Thank you for the feedback!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

  reply	other threads:[~2026-10-23 13:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 13:33 Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 01/12] rcu_txn: Add single-writer " Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 02/12] rcu_txn: Add KUnit tests Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 03/12] rcu_txn: Skip the record lookup with a Bloom filter Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 04/12] rcu_txn: Add CONFIG_DEBUG_RCU_TXN Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 05/12] rcu_txn: Add an hlist edited through transactions Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 06/12] rcu_txn: Add a doubly-linked list coherent in both directions Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 07/12] Documentation/RCU: Describe RCU pseudo-transactions Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 08/12] Documentation/litmus-tests: Add RCU pseudo-transaction tests Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 09/12] rcu_txn: Test a list writer against concurrent readers Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 10/12] rcu_txn: Test a commit from atomic context Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 11/12] samples: Add a cache on RCU pseudo-transactions under one mutex Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 12/12] samples: Add a cache on RCU pseudo-transactions with a lock per node Mathieu Desnoyers
2026-10-23 18:22   ` Puranjay Mohan
2026-10-19  0:55 ` [RFC PATCH 00/12] RCU pseudo-transactions Joel Fernandes
2026-10-23 13:37   ` Mathieu Desnoyers [this message]
2026-10-23 18:19 ` Puranjay Mohan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f1e23a9-7d42-4a50-98d0-c932a2db4b8e@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=aliceryhl@google.com \
    --cc=andrewjballance@gmail.com \
    --cc=boqun@kernel.org \
    --cc=brauner@kernel.org \
    --cc=frederic@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joelagnelf@nvidia.com \
    --cc=josh@joshtriplett.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qiang.zhang@linux.dev \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®