Trond Myklebust [EMAIL PROTECTED] wrote:
AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
order to try to take the lock (or queue the waiter if that fails), then
once more in order to pass the mutex on to the next waiter on
up()/mutex_unlock(). That is more or less the
Benjamin LaHaise [EMAIL PROTECTED] wrote:
What about the use of atomic operations on frv? Are they more lightweight
than a semaphore, making for a better fastpath?
What do you mean? Atomic ops don't compare to semaphores.
On FRV atomic ops don't disable interrupts; they reserve one of the
Benjamin LaHaise [EMAIL PROTECTED] wrote:
Oh dear, this is going to take a while. In any case, here is such a
first step in creating such a sequence of patches. Located at
http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches:
...
10_new_mutex.diff - Replaces the
fr den 15.04.2005 Klokka 17:13 (+0100) skreiv David Howells:
Can I suggest you don't use a wait_queue_t in your mutex? The way you've
implemented your mutex you appear to have to take spinlocks and disable
interrupts a lot more than is necessary.
You might want to look at how I've implemented
On Fri, Apr 08, 2005 at 07:31:46PM -0400, Trond Myklebust wrote:
fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise:
On the aio side of things, I introduced the owner field in the mutex (as
opposed to the flag in Trond's iosem) for the next patch in the series to
enable
On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote:
- switch all current semaphore users that don't need counting semaphores
over to use a mutex_t type. For now it can map to struct semaphore.
- rip out all existing complicated struct semaphore implementations and
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
IOW: the current semaphore implementations really all need to die, and
be replaced by a single generic version to which it is actually
practical to add new
On Tue, Apr 05, 2005 at 09:20:57PM -0400, Trond Myklebust wrote:
ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise:
I can see that goal, but I don't think introducing iosems is the right
way to acheive it. Instead (and I'll start tackling this), how about
factoring out the
m den 04.04.2005 Klokka 12:22 (-0400) skreiv Benjamin LaHaise:
Your approach looks reasonable and simple enough. It'd be useful if I
could visualize the caller side of things as in the NFS client stream
as you mention - do you plan to post that soon ?
I'm tempted to think about the
Trond Myklebust writes:
In NFSv4 we often want to serialize asynchronous RPC calls with ordinary
[...]
+
+void fastcall iosem_lock(struct iosem *lk)
+{
+struct iosem_wait waiter;
+
+might_sleep();
+
+init_iosem_waiter(waiter);
+waiter.wait.func =
to den 31.03.2005 Klokka 21:09 (+0400) skreiv Nikita Danilov:
You are assuming that all the waiters on the queue are tasks that must
sleep if they cannot take the lock. That is not the case here. Whereas
some users will indeed fall in this category, I expect that most will
rather want
to den 31.03.2005 Klokka 12:22 (-0500) skreiv Trond Myklebust:
That would be equally confusing. The lock exists to serialize _BOTH_
tasks and work queue items.
For instance the NFSv4 OPEN takes the token synchronously, and it needs
to be serialized w.r.t. the asynchronous CLOSE or
Trond Myklebust [EMAIL PROTECTED] wrote:
on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
Or have I misunderstood the intent? Some /* comments */ would be
appropriate..
Will do.
OK. Plenty of comments added that will hopefully clarify what is going
on and how
to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton:
Trond Myklebust [EMAIL PROTECTED] wrote:
on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
Or have I misunderstood the intent? Some /* comments */ would be
appropriate..
Will do.
OK. Plenty of
In NFSv4 we often want to serialize asynchronous RPC calls with ordinary
RPC calls (OPEN and CLOSE for instance). On paper, semaphores would
appear to fit the bill, however there is no support for asynchronous I/O
with semaphores.
rantWhat's more, trying to add that type of support is an exercise
Trond Myklebust [EMAIL PROTECTED] wrote:
In NFSv4 we often want to serialize asynchronous RPC calls with ordinary
RPC calls (OPEN and CLOSE for instance). On paper, semaphores would
appear to fit the bill, however there is no support for asynchronous I/O
with semaphores.
rantWhat's more,
Trond Myklebust [EMAIL PROTECTED] wrote:
This is required in order to allow threads such as rpciod or keventd
itself (for which sleeping may cause deadlocks) to ask the iosem manager
code to simply queue the work that need to run once the iosem has been
granted. That work function is then, of
on den 30.03.2005 Klokka 15:44 (-0800) skreiv Andrew Morton:
Trond Myklebust [EMAIL PROTECTED] wrote:
This is required in order to allow threads such as rpciod or keventd
itself (for which sleeping may cause deadlocks) to ask the iosem manager
code to simply queue the work that need to
on den 30.03.2005 Klokka 14:34 (-0800) skreiv Andrew Morton:
Anyhow, the following is a simple implementation of semaphores designed
to satisfy the needs of those I/O subsystems that want to support
asynchronous behaviour too. Please comment.
So I've been staring at this code for a
19 matches
Mail list logo
