From: Peter Zijlstra <peterz@infradead.org>
To: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Mason <chris.mason@oracle.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()
Date: Tue, 29 Mar 2011 19:37:33 +0200 [thread overview]
Message-ID: <1301420253.2250.430.camel@laptop> (raw)
In-Reply-To: <20110329170949.GF29865@htj.dyndns.org>
On Tue, 2011-03-29 at 19:09 +0200, Tejun Heo wrote:
> Here's the combined patch I was planning on testing but didn't get to
> (yet). It implements two things - hard limit on spin duration and
> early break if the owner also is spinning on a mutex.
This is going to give massive conflicts with
https://lkml.org/lkml/2011/3/2/286
https://lkml.org/lkml/2011/3/2/282
which I was planning to stuff into .40
> @@ -4021,16 +4025,44 @@ EXPORT_SYMBOL(schedule);
>
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> /*
> + * Maximum mutex owner spin duration in nsecs. Don't spin more then
> + * DEF_TIMESLICE.
> + */
> +#define MAX_MUTEX_SPIN_NS (DEF_TIMESLICE * 1000000000LLU / HZ)
DEF_TIMESLICE is SCHED_RR only, so its use here is dubious at best, also
I bet we have something like NSEC_PER_SEC to avoid counting '0's.
> +
> +/**
> + * mutex_spin_on_owner - optimistic adaptive spinning on locked mutex
> + * @lock: the mutex to spin on
> + * @owner: the current owner (speculative pointer)
> + *
> + * The caller is trying to acquire @lock held by @owner. If @owner is
> + * currently running, it might get unlocked soon and spinning on it can
> + * save the overhead of sleeping and waking up.
> + *
> + * Note that @owner is completely speculative and may be completely
> + * invalid. It should be accessed very carefully.
> + *
> + * Forward progress is guaranteed regardless of locking ordering by never
> + * spinning longer than MAX_MUTEX_SPIN_NS. This is necessary because
> + * mutex_trylock(), which doesn't have to follow the usual locking
> + * ordering, also uses this function.
While that puts a limit on things it'll still waste time. I'd much
rather pass an trylock argument to mutex_spin_on_owner() and then bail
on owner also spinning.
> + * CONTEXT:
> + * Preemption disabled.
> + *
> + * RETURNS:
> + * %true if the lock was released and the caller should retry locking.
> + * %false if the caller better go sleeping.
> */
> -int mutex_spin_on_owner(struct mutex *lock, struct thread_info *owner)
> +bool mutex_spin_on_owner(struct mutex *lock, struct thread_info *owner)
> {
> @@ -4070,21 +4104,30 @@ int mutex_spin_on_owner(struct mutex *lo
> * we likely have heavy contention. Return 0 to quit
> * optimistic spinning and not contend further:
> */
> + ret = !lock->owner;
> break;
> }
>
> /*
> - * Is that owner really running on that cpu?
> + * Quit spinning if any of the followings is true.
> + *
> + * - The owner isn't running on that cpu.
> + * - The owner also is spinning on a mutex.
> + * - Someone else wants to use this cpu.
> + * - We've been spinning for too long.
> */
> + if (task_thread_info(rq->curr) != owner ||
> + rq->spinning_on_mutex || need_resched() ||
> + local_clock() > start + MAX_MUTEX_SPIN_NS) {
While we did our best with making local_clock() cheap, I'm still fairly
uncomfortable with putting it in such a tight loop.
> + ret = false;
> + break;
> + }
>
> arch_mutex_cpu_relax();
> }
>
> + this_rq()->spinning_on_mutex = false;
> + return ret;
> }
> #endif
>
next prev parent reply other threads:[~2011-03-29 17:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 15:37 [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock() Tejun Heo
2011-03-23 15:40 ` Tejun Heo
2011-03-23 15:48 ` Linus Torvalds
2011-03-23 15:52 ` Tejun Heo
2011-03-23 19:46 ` Andrey Kuzmin
2011-03-24 8:18 ` Ingo Molnar
2011-03-25 3:24 ` Steven Rostedt
2011-03-25 10:29 ` Ingo Molnar
2011-03-24 9:41 ` [PATCH 1/2] Subject: mutex: Separate out mutex_spin() Tejun Heo
2011-03-24 9:41 ` [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock() Tejun Heo
2011-03-25 3:39 ` Steven Rostedt
2011-03-25 4:38 ` Linus Torvalds
2011-03-25 6:53 ` Tejun Heo
2011-03-25 13:10 ` Steven Rostedt
2011-03-25 13:29 ` Steven Rostedt
2011-03-25 11:13 ` Andrey Kuzmin
2011-03-25 13:12 ` Steven Rostedt
2011-03-25 13:50 ` Andrey Kuzmin
2011-03-25 14:05 ` Steven Rostedt
2011-03-25 19:51 ` Ingo Molnar
2011-03-25 10:12 ` Tejun Heo
2011-03-25 10:31 ` Ingo Molnar
2011-03-29 16:37 ` Tejun Heo
2011-03-29 17:09 ` Tejun Heo
2011-03-29 17:37 ` Peter Zijlstra [this message]
2011-03-30 8:17 ` Tejun Heo
2011-03-30 11:29 ` Peter Zijlstra
2011-03-30 11:46 ` Chris Mason
2011-03-30 11:52 ` Peter Zijlstra
2011-03-30 11:59 ` Chris Mason
2011-03-24 9:42 ` [PATCH 1/2] Subject: mutex: Separate out mutex_spin() Tejun Heo
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=1301420253.2250.430.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/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).