Messages in this thread | | | Date | Fri, 28 Jan 2005 20:45:46 +0100 | From | Ingo Molnar <> | Subject | Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) |
| |
* Trond Myklebust <trond.myklebust@fys.uio.no> 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 recovery > code. The point is that when the server reboots, the server forces us > to block *all* requests that involve adding new state (e.g. opening an > NFSv4 file, or setting up a lock) while our client and others are > re-establishing their existing state on the server.
it seems the most scalable solution for this would be a global flag plus per-CPU spinlocks (or per-CPU mutexes) to make this totally scalable and still support the requirements of this rare event. An rwsem really bounces around on SMP, and it seems very unnecessary in the case you described.
possibly this could be formalised as an rwlock/rwlock implementation that scales better. brlocks were such an attempt.
> IOW: If you are planning on converting rwsems into a semaphore, you > will screw us over most royally, by converting the currently highly > infrequent scenario of a single task being able to access the server > into the common case.
nono, i have no such plans.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |