For anybody who wants a good executive summary of RCU, see these:
http://lse.sourceforge.net/locking/rcupdate.html
http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS
On Jan 30, 2005, at 17:03, Esben Nielsen wrote:
I agree that RCU ought to do the trick in a lot of cases.
On Fri, 28 Jan 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > I noticed that you changed rw-locks to behave quite diferently under
> > real-time preemption: They basicly works like normal locks now. I.e.
> > there can only be one reader task within each region.
On Fri, Jan 28, 2005 at 08:45:46PM +0100, Ingo Molnar wrote:
> * Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > If you do have a highest interrupt case that causes all activity to
> > block, then rwsems may indeed fit the bill.
> >
> > In the NFS client code we may use rwsems in order to protect
On Fri, 2005-01-28 at 11:18 -0800, Trond Myklebust wrote:
> In the NFS client code we may use rwsems in order to protect stateful
> operations against the (very infrequently used) server reboot recovery
> code. The point is that when the server reboots, the server forces us to
> block *all*
* Trond Myklebust <[EMAIL PROTECTED]> wrote:
> If you do have a highest interrupt case that causes all activity to
> block, then rwsems may indeed fit the bill.
>
> In the NFS client code we may use rwsems in order to protect stateful
> operations against the (very infrequently used) server
fr den 28.01.2005 Klokka 08:38 (+0100) skreiv Ingo Molnar:
> no, it's not a big scalability problem. rwlocks are really a mistake -
> if you want scalability and spinlocks/semaphores are not enough then one
> should either use per-CPU locks or lockless structures. rwlocks/rwsems
> will very
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> The performance relative to mutual exclusion is quantifiable and very
> reproducible. [...]
yes, i dont doubt the results - my point is that it's not proven that
the other, more read-friendly types of locking underperform rwlocks.
Obviously
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> I wouldn't be so sure about that. SGI is already implicitly relying on
>> the parallel holding of rwsems for the lockless pagefaulting, and
>> Oracle has been pushing on mapping->tree_lock becoming an rwlock for a
>> while, both for large
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
> > no, it's not a big scalability problem. rwlocks are really a mistake -
> > if you want scalability and spinlocks/semaphores are not enough then one
> > should either use per-CPU
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
>> [...] I wanted to start looking at fixing that because it ought to
>> hurt scalability quite a bit - and even on UP create a few unneeded
>> task-switchs. [...]
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
> no, it's not a big
* Esben Nielsen [EMAIL PROTECTED] wrote:
[...] I wanted to start looking at fixing that because it ought to
hurt scalability quite a bit - and even on UP create a few unneeded
task-switchs. [...]
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
no, it's not a big scalability
* William Lee Irwin III [EMAIL PROTECTED] wrote:
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
no, it's not a big scalability problem. rwlocks are really a mistake -
if you want scalability and spinlocks/semaphores are not enough then one
should either use per-CPU locks or
* William Lee Irwin III [EMAIL PROTECTED] wrote:
I wouldn't be so sure about that. SGI is already implicitly relying on
the parallel holding of rwsems for the lockless pagefaulting, and
Oracle has been pushing on mapping-tree_lock becoming an rwlock for a
while, both for large performance
* William Lee Irwin III [EMAIL PROTECTED] wrote:
The performance relative to mutual exclusion is quantifiable and very
reproducible. [...]
yes, i dont doubt the results - my point is that it's not proven that
the other, more read-friendly types of locking underperform rwlocks.
Obviously
fr den 28.01.2005 Klokka 08:38 (+0100) skreiv Ingo Molnar:
no, it's not a big scalability problem. rwlocks are really a mistake -
if you want scalability and spinlocks/semaphores are not enough then one
should either use per-CPU locks or lockless structures. rwlocks/rwsems
will very unlikely
* Trond Myklebust [EMAIL PROTECTED] wrote:
If you do have a highest interrupt case that causes all activity to
block, then rwsems may indeed fit the bill.
In the NFS client code we may use rwsems in order to protect stateful
operations against the (very infrequently used) server reboot
On Fri, 2005-01-28 at 11:18 -0800, Trond Myklebust wrote:
In the NFS client code we may use rwsems in order to protect stateful
operations against the (very infrequently used) server reboot recovery
code. The point is that when the server reboots, the server forces us to
block *all* requests
On Fri, Jan 28, 2005 at 08:45:46PM +0100, Ingo Molnar wrote:
* Trond Myklebust [EMAIL PROTECTED] wrote:
If you do have a highest interrupt case that causes all activity to
block, then rwsems may indeed fit the bill.
In the NFS client code we may use rwsems in order to protect stateful
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> I noticed that you changed rw-locks to behave quite diferently under
> real-time preemption: They basicly works like normal locks now. I.e.
> there can only be one reader task within each region. This can can
> however lock the region recursively.
* Esben Nielsen [EMAIL PROTECTED] wrote:
I noticed that you changed rw-locks to behave quite diferently under
real-time preemption: They basicly works like normal locks now. I.e.
there can only be one reader task within each region. This can can
however lock the region recursively. [...]
20 matches
Mail list logo
