linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Davidlohr Bueso <dave@stgolabs.net>,
	"Theodore Y. Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH] locking/rwsem: Add up_write_non_owner() for percpu_up_write()
Date: Mon, 9 Apr 2018 09:32:49 -0400	[thread overview]
Message-ID: <38c89c59-5ff0-20df-2628-880db397006e@redhat.com> (raw)
In-Reply-To: <20180409112013.GA23240@redhat.com>

On 04/09/2018 07:20 AM, Oleg Nesterov wrote:
> On 04/04, Waiman Long wrote:
>> --- a/kernel/locking/percpu-rwsem.c
>> +++ b/kernel/locking/percpu-rwsem.c
>> @@ -179,8 +179,10 @@ void percpu_up_write(struct percpu_rw_semaphore *sem)
>>  
>>  	/*
>>  	 * Release the write lock, this will allow readers back in the game.
>> +	 * percpu_up_write() may be called from a task different from the one
>> +	 * taking the lock.
>>  	 */
>> -	up_write(&sem->rw_sem);
>> +	up_write_non_owner(&sem->rw_sem);
>>  
>>  	/*
>>  	 * Once this completes (at least one RCU-sched grace period hence) the
>> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
>> index 30465a2..140d5ef 100644
>> --- a/kernel/locking/rwsem.c
>> +++ b/kernel/locking/rwsem.c
>> @@ -222,4 +222,17 @@ void up_read_non_owner(struct rw_semaphore *sem)
>>  
>>  #endif
>>  
>> +#ifdef CONFIG_DEBUG_RWSEMS
>> +/*
>> + * release a write lock from a different task
>> + */
>> +void up_write_non_owner(struct rw_semaphore *sem)
>> +{
>> +	rwsem_release(&sem->dep_map, 1, _RET_IP_);
>> +	DEBUG_RWSEMS_WARN_ON(!sem->owner || (sem->owner == RWSEM_READER_OWNED));
>>  
>> +	rwsem_clear_owner(sem);
>> +	__up_write(sem);
>> +}
> Hmm. Can you look at lockdep_sb_freeze_release() and lockdep_sb_freeze_acquire()?

These 2 functions are there to deal with the lockdep code.

> At first glance, it would be much better to set sem->owner = current in
> percpu_rwsem_acquire(), no?

The primary purpose of the owner field is to enable optimistic spinning
to improve locking performance. So it needs to be set during an
up_write() call.

My rwsem debug patch does use it also to check for consistency in the
use of lock/unlock call. Anyway, I don't think it is right to set it
again in percpu_rwsem_acquire() if there is no guarantee that the task
that call percpu_rwsem_acquire will be the one that will do the unlock.

I am wondering if it makes sense to do optimistic spinning in the case
of percpu_rwsem where the unlocker may be a different task. We could set
a special code for writer owned lock, but don't do optimistic spinning
in this case.

Cheers,
Longman

  reply	other threads:[~2018-04-09 13:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 14:37 [PATCH] locking/rwsem: Add up_write_non_owner() for percpu_up_write() Waiman Long
2018-04-04 14:40 ` Waiman Long
2018-04-05  3:14 ` Theodore Y. Ts'o
2018-04-09 11:20 ` Oleg Nesterov
2018-04-09 13:32   ` Waiman Long [this message]
2018-04-09 14:22     ` Oleg Nesterov
2018-05-14 19:36       ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38c89c59-5ff0-20df-2628-880db397006e@redhat.com \
    --to=longman@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).