| 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
| ||
|
Message-ID: <20110307225110.GA19414@tsunami.ccur.com> Date: Mon, 7 Mar 2011 17:51:10 -0500 From: Joe Korty <joe.korty@...r.com> To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@...il.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] An RCU for SMP with a single CPU garbage collector On Mon, Mar 07, 2011 at 04:16:13PM -0500, Joe Korty wrote: > On Mon, Mar 07, 2011 at 04:01:57PM -0500, Paul E. McKenney wrote: >> But I would really prefer leveraging the existing RCU implementations >> to the extent possible. Are the user-dedicated CPUs able to invoke >> system calls? If so, something like Frederic's approach should permit >> the existing RCU implementations to operate normally. If not, what is >> doing the RCU read-side critical sections on the dedicated CPUs? > > I thought about the system call approach but rejected it. > Some (maybe many) customers needing dedicated CPUs will > have apps that never make any system calls at all. Hi Paul, Thinking about it some more, the tap-into-syscall approach might work in my implementation, in which case the tap-into-preempt-enable code could go away. Nice thing about RCU, the algorithms are infinitely mallable :) Joe -- 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/
Powered by blists - more mailing lists