On Tue, May 15, 2018 at 09:57:44AM -0400, Waiman Long wrote:
> > Afaict the whole .owner=NULL thing in release already stops the spinners
> > dead, and the above 'fixes' the debug splat. And this avoids exposing
> > that horrible interface and keeps the mucking private to
> > rwsem/percpu_rwsem.
>
On Tue, May 15, 2018 at 09:57:44AM -0400, Waiman Long wrote:
> > Afaict the whole .owner=NULL thing in release already stops the spinners
> > dead, and the above 'fixes' the debug splat. And this avoids exposing
> > that horrible interface and keeps the mucking private to
> > rwsem/percpu_rwsem.
>
On 05/15/2018 04:51 AM, Peter Zijlstra wrote:
> On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however, may
>> take a while to get the ownership of
On 05/15/2018 04:51 AM, Peter Zijlstra wrote:
> On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however, may
>> take a while to get the ownership of
On 05/15/2018 01:42 AM, Amir Goldstein wrote:
> On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however, may
>> take a while to get the
On 05/15/2018 01:42 AM, Amir Goldstein wrote:
> On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however, may
>> take a while to get the ownership of the
On Tue, May 15, 2018 at 02:45:32PM +0200, Oleg Nesterov wrote:
> On 05/15, Peter Zijlstra wrote:
> >
> > > > Afaict the whole .owner=NULL thing in release already stops the spinners
> > >
> > > Not really, the new writer will spin in this case, afaics.
> > >
> > > But this is another problem and
On Tue, May 15, 2018 at 02:45:32PM +0200, Oleg Nesterov wrote:
> On 05/15, Peter Zijlstra wrote:
> >
> > > > Afaict the whole .owner=NULL thing in release already stops the spinners
> > >
> > > Not really, the new writer will spin in this case, afaics.
> > >
> > > But this is another problem and
On 05/15, Peter Zijlstra wrote:
>
> > > Afaict the whole .owner=NULL thing in release already stops the spinners
> >
> > Not really, the new writer will spin in this case, afaics.
> >
> > But this is another problem and probably we do not care. The new writer is
> > almost impossible in this
On 05/15, Peter Zijlstra wrote:
>
> > > Afaict the whole .owner=NULL thing in release already stops the spinners
> >
> > Not really, the new writer will spin in this case, afaics.
> >
> > But this is another problem and probably we do not care. The new writer is
> > almost impossible in this
On Tue, May 15, 2018 at 01:06:33PM +0200, Oleg Nesterov wrote:
> On 05/15, Peter Zijlstra wrote:
> >
> > So what's wrong with adding:
> >
> > if (!read)
> > sem->rw_sem.owner = current;
>
> Agreed, I have already suggested this change twice. Except we obviously
> need to check
On Tue, May 15, 2018 at 01:06:33PM +0200, Oleg Nesterov wrote:
> On 05/15, Peter Zijlstra wrote:
> >
> > So what's wrong with adding:
> >
> > if (!read)
> > sem->rw_sem.owner = current;
>
> Agreed, I have already suggested this change twice. Except we obviously
> need to check
On 05/15, Jan Kara wrote:
>
> Now this behavior upsets lockdep and that's why we fool it by telling the
> semaphore got released before returning to userspace (through
> percpu_rwsem_release() helper) and similarly we tell lockdep we've got the
> semaphore when an unfreeze syscall is called by
On 05/15, Jan Kara wrote:
>
> Now this behavior upsets lockdep and that's why we fool it by telling the
> semaphore got released before returning to userspace (through
> percpu_rwsem_release() helper) and similarly we tell lockdep we've got the
> semaphore when an unfreeze syscall is called by
On 05/15, Peter Zijlstra wrote:
>
> So what's wrong with adding:
>
> if (!read)
> sem->rw_sem.owner = current;
Agreed, I have already suggested this change twice. Except we obviously
need to check CONFIG_RWSEM_SPIN_ON_OWNER (->owner doesn't exists otherwise)
or even
On 05/15, Peter Zijlstra wrote:
>
> So what's wrong with adding:
>
> if (!read)
> sem->rw_sem.owner = current;
Agreed, I have already suggested this change twice. Except we obviously
need to check CONFIG_RWSEM_SPIN_ON_OWNER (->owner doesn't exists otherwise)
or even
On Tue 15-05-18 10:35:25, Peter Zijlstra wrote:
> On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> > The percpu_rwsem_release() is called when the ownership of the embedded
> > rwsem is to be transferred to another task. The new owner, however, may
> > take a while to get the
On Tue 15-05-18 10:35:25, Peter Zijlstra wrote:
> On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> > The percpu_rwsem_release() is called when the ownership of the embedded
> > rwsem is to be transferred to another task. The new owner, however, may
> > take a while to get the
On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that
On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that
On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that
On Mon, May 14, 2018 at 03:31:07PM -0400, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that
On Tue, May 15, 2018 at 8:42 AM, Amir Goldstein wrote:
> On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however,
On Tue, May 15, 2018 at 8:42 AM, Amir Goldstein wrote:
> On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
>> The percpu_rwsem_release() is called when the ownership of the embedded
>> rwsem is to be transferred to another task. The new owner, however, may
>> take a while to get the ownership
On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
On Mon, May 14, 2018 at 10:31 PM, Waiman Long wrote:
> The percpu_rwsem_release() is called when the ownership of the embedded
> rwsem is to be transferred to another task. The new owner, however, may
> take a while to get the ownership of the lock via percpu_rwsem_acquire().
> During that
26 matches
Mail list logo