[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1005171532430.4195@i5.linux-foundation.org>
Date: Mon, 17 May 2010 15:44:24 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Michel Lespinasse <walken@...gle.com>
cc: David Howells <dhowells@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Waychison <mikew@...gle.com>,
Suleiman Souhlal <suleiman@...gle.com>,
Ying Han <yinghan@...gle.com>
Subject: Re: [PATCH 07/10] generic rwsem: implement down_read_critical() /
up_read_critical()
On Mon, 17 May 2010, Michel Lespinasse wrote:
>
> Add down_read_critical() / up_read_critical() API.
>
> down_read_critical() is similar to down_read() with the following changes:
> - when the rwsem is read owned with queued writers, down_read_unfair() callers
> are allowed to acquire the rwsem for read without queueing;
You didn't update the comment for the new name here...
> - when the rwsem is write owned, down_read_unfair() callers get queued in
> front of threads trying to acquire the rwsem by other means.
.. or here. In this case, it really is more about "unfairness", but I'm
not convinced it should be so in the naming anyway, even if internally it
might be __down_read_unfair. "critical" I think covers both.
> - caller can't sleep until releasing lock with up_read_critical(),
> and preemption is disabled for that time.
But you did here (because it's a new thing).
Anyway, the series looks mostly acceptable to me in this form. I think it
conceptually works out, and I think that the non-preemption guarantee
should mean that starvation of writers is not likely an issue. However,
I'd definitely like some second opinions on it. I'm not going to apply
this series without acks from people. So you should try to convince DavidH
too that this actually really does matter and makes sense.
Linus
--
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