Message-ID: <1429824690.10273.41.camel@stgolabs.net>
Subject: Re: [PATCH v2] locking/rwsem: reduce spinlock contention in wakeup
 after up_read/up_write
From: Davidlohr Bueso <dave@stgolabs.net>
To: Waiman Long <Waiman.Long@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel@vger.kernel.org, Jason Low <jason.low2@hp.com>,
        Scott J Norton <scott.norton@hp.com>,
        Douglas Hatch <doug.hatch@hp.com>
Date: Thu, 23 Apr 2015 14:31:30 -0700
In-Reply-To: <1429813449-19641-1-git-send-email-Waiman.Long@hp.com>
References: <1429813449-19641-1-git-send-email-Waiman.Long@hp.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1183
Lines: 29

It would be nice to not run into this by accident. Please CC all
relevant parties ;)

On Thu, 2015-04-23 at 14:24 -0400, Waiman Long wrote:
> In up_read()/up_write(), rwsem_wake() will be called whenever it
> detects that some writers/readers are waiting. The rwsem_wake()
> function will take the wait_lock and call __rwsem_do_wake() to do
> the real wakeup.  This can be a problem especially for up_read()
> where many readers can potentially call rwsem_wake() at more or less
> the same time even though a single call should be enough. This will
> cause contention in the wait_lock cacheline resulting in delay of
> the up_read/up_write operations.

Ok.

> This patch makes the wait_lock taking and the call to __rwsem_do_wake()
> optional if at least one spinning writer is present.

But if the lock is taken by readers, like you suggest above, there
cannot be any active spinners. We always block in these cases.

Thanks,
Davidlohr

--
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/