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: 45+ 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:37 ` Tejun Heo
2011-03-23 15:40 ` Tejun Heo
2011-03-23 15:40 ` Tejun Heo
2011-03-23 15:48 ` Linus Torvalds
2011-03-23 15:48 ` Linus Torvalds
2011-03-23 15:52 ` Tejun Heo
2011-03-23 15:52 ` Tejun Heo
2011-03-23 19:46 ` Andrey Kuzmin
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 ` Tejun Heo
2011-03-24 9:41 ` [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock() Tejun Heo
2011-03-24 9:41 ` 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 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:12 ` Tejun Heo
2011-03-25 10:31 ` Ingo Molnar
2011-03-29 16:37 ` Tejun Heo
2011-03-29 16:37 ` Tejun Heo
2011-03-29 17:09 ` 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
2011-03-24 9:42 ` Tejun Heo
2011-03-24 16:18 ` [tip:core/urgent] " tip-bot for Tejun Heo
2011-03-24 16:19 ` [tip:core/urgent] mutex: Do adaptive spinning in mutex_trylock() tip-bot for 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.