On 09/30/2013 03:05 AM, Ingo Molnar wrote:
* Michel Lespinasse<wal...@google.com> wrote:
That said, I am very scared of using rwlock_t here, and I would much
prefer we choose a fair lock (either spinlock or a new rwlock
implementation which guarantees not to starve any locker thread)
Given how few users rwlock_t has today we could attempt to make it
reader-writer fair, as long as the usecase of a hardirq or softirq
context always getting nested read access on the same CPU is preserved.
(but that can be done - if nothing else then with an explicit context
check.)
Thanks,
Ingo
My queue rwlock patch is able to handle the use case of a hardirq and
softirq context and can be made almost as fair as the ticket spinlock.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
