All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>,
	Waiman Long <Waiman.Long-VXdhtT5mjnY@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Davidlohr Bueso <davidlohr-VXdhtT5mjnY@public.gmane.org>,
	Heiko Carstens
	<heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jason Low <jason.low2-VXdhtT5mjnY@public.gmane.org>,
	Scott J Norton <scott.norton-VXdhtT5mjnY@public.gmane.org>
Subject: Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex
Date: Mon, 21 Jul 2014 10:41:09 -0700	[thread overview]
Message-ID: <CFF29E4A.9D44E%dvhart@linux.intel.com> (raw)
In-Reply-To: <CFF29A00.9D44A%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

On 7/21/14, 10:20, "Darren Hart" <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:

>On 7/21/14, 9:45, "Andi Kleen" <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
>
>>Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>>
>>> Waiman Long <Waiman.Long-VXdhtT5mjnY@public.gmane.org> writes:
>>>
>>>> This patch series introduces two new futex command codes to support
>>>> a new optimistic spinning futex for implementing an exclusive lock
>>>> primitive that should perform better than the same primitive using
>>>> the wait-wake futex in cases where the lock owner is actively working
>>>> instead of waiting for I/O completion.
>>>
>>> How would you distinguish those two cases automatically?
>>
>>Also BTW traditionally the spinning was just done in user space.
>>
>>This would be always even more efficient, because it would
>>even avoid the syscall entry path.
>>
>>Given the glibc adaptive mutexes are not very good, but I'm sure those
>>could be improved.
>
>I presented on something along these lines a few years back, and various
>people have asked for the sample code over the years. Andi is right,
>doing 
>this from user-space has the potential to be more efficient, the
>challenge 
>is getting access to privileged information, such as the state of the
>mutex owner. You don't want to spin if the owner is sleeping. I did this
>by adding a tidrunning call to the vdso. My somewhat hacked solution is
>still available here:
>
>http://git.infradead.org/users/dvhart/linux.git/shortlog/refs/heads/futex/
>t
>idrunning/dev
>
>
>I abandoned the spinning in the kernel thing due to the overhead of the
>system call if I remember correctly. Also available here:
>
>http://git.infradead.org/users/dvhart/linux.git/shortlog/refs/heads/futex/
>f
>utex-lock-adaptive
>

And the associated Linux Plumbers 2010 presentation which I can't seem to
find archived anywhere else:

http://dvhart.com/darren/files/kernel-assisted-userspace-adaptive-mutexes.p
df


We observed some significant improvements under some very specific use
cases, but a more thorough dive into performance impact in the other cases
as well as security implications with the vdso is still wanting.

-- 
Darren Hart					Open Source Technology Center
darren.hart-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org				            Intel Corporation

WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhart@linux.intel.com>
To: Andi Kleen <andi@firstfloor.org>, Waiman Long <Waiman.Long@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	<linux-kernel@vger.kernel.org>, <linux-api@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, Jason Low <jason.low2@hp.com>,
	Scott J Norton <scott.norton@hp.com>
Subject: Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex
Date: Mon, 21 Jul 2014 10:41:09 -0700	[thread overview]
Message-ID: <CFF29E4A.9D44E%dvhart@linux.intel.com> (raw)
In-Reply-To: <CFF29A00.9D44A%dvhart@linux.intel.com>

On 7/21/14, 10:20, "Darren Hart" <dvhart@linux.intel.com> wrote:

>On 7/21/14, 9:45, "Andi Kleen" <andi@firstfloor.org> wrote:
>
>>Andi Kleen <andi@firstfloor.org> writes:
>>
>>> Waiman Long <Waiman.Long@hp.com> writes:
>>>
>>>> This patch series introduces two new futex command codes to support
>>>> a new optimistic spinning futex for implementing an exclusive lock
>>>> primitive that should perform better than the same primitive using
>>>> the wait-wake futex in cases where the lock owner is actively working
>>>> instead of waiting for I/O completion.
>>>
>>> How would you distinguish those two cases automatically?
>>
>>Also BTW traditionally the spinning was just done in user space.
>>
>>This would be always even more efficient, because it would
>>even avoid the syscall entry path.
>>
>>Given the glibc adaptive mutexes are not very good, but I'm sure those
>>could be improved.
>
>I presented on something along these lines a few years back, and various
>people have asked for the sample code over the years. Andi is right,
>doing 
>this from user-space has the potential to be more efficient, the
>challenge 
>is getting access to privileged information, such as the state of the
>mutex owner. You don't want to spin if the owner is sleeping. I did this
>by adding a tidrunning call to the vdso. My somewhat hacked solution is
>still available here:
>
>http://git.infradead.org/users/dvhart/linux.git/shortlog/refs/heads/futex/
>t
>idrunning/dev
>
>
>I abandoned the spinning in the kernel thing due to the overhead of the
>system call if I remember correctly. Also available here:
>
>http://git.infradead.org/users/dvhart/linux.git/shortlog/refs/heads/futex/
>f
>utex-lock-adaptive
>

And the associated Linux Plumbers 2010 presentation which I can't seem to
find archived anywhere else:

http://dvhart.com/darren/files/kernel-assisted-userspace-adaptive-mutexes.p
df


We observed some significant improvements under some very specific use
cases, but a more thorough dive into performance impact in the other cases
as well as security implications with the vdso is still wanting.

-- 
Darren Hart					Open Source Technology Center
darren.hart@intel.com				            Intel Corporation




  parent reply	other threads:[~2014-07-21 17:41 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 15:24 [RFC PATCH 0/5] futex: introduce an optimistic spinning futex Waiman Long
2014-07-21 15:24 ` [RFC PATCH 1/5] futex: add new exclusive lock & unlock command codes Waiman Long
2014-07-21 16:42   ` Thomas Gleixner
2014-07-22 18:22     ` Waiman Long
     [not found]       ` <53CEABD7.3030509-VXdhtT5mjnY@public.gmane.org>
2014-07-22 21:00         ` Thomas Gleixner
2014-07-22 21:00           ` Thomas Gleixner
     [not found] ` <1405956271-34339-1-git-send-email-Waiman.Long-VXdhtT5mjnY@public.gmane.org>
2014-07-21 15:24   ` [RFC PATCH 2/5] futex: add optimistic spinning to FUTEX_SPIN_LOCK Waiman Long
2014-07-21 15:24     ` Waiman Long
     [not found]     ` <1405956271-34339-3-git-send-email-Waiman.Long-VXdhtT5mjnY@public.gmane.org>
2014-07-21 17:15       ` Davidlohr Bueso
2014-07-21 17:15         ` Davidlohr Bueso
     [not found]         ` <1405962929.11927.19.camel-5JQ4ckphU/8SZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
2014-07-22 18:46           ` Waiman Long
2014-07-22 18:46             ` Waiman Long
2014-07-21 20:17     ` Jason Low
2014-07-22 19:34       ` Waiman Long
2014-07-21 15:24 ` [RFC PATCH 3/5] spinning futex: move a wakened task to spinning Waiman Long
2014-07-21 15:24 ` [RFC PATCH 4/5] spinning futex: put waiting tasks in a sorted rbtree Waiman Long
2014-07-21 15:24 ` [RFC PATCH 5/5] futex, doc: add a document on how to use the spinning futexes Waiman Long
2014-07-21 15:45   ` Randy Dunlap
2014-07-22  3:19     ` Waiman Long
2014-07-21 16:42 ` [RFC PATCH 0/5] futex: introduce an optimistic spinning futex Andi Kleen
2014-07-21 16:45   ` Andi Kleen
     [not found]     ` <871tte3bjw.fsf-KWJ+5VKanrL29G5dvP0v1laTQe2KTcn/@public.gmane.org>
2014-07-21 17:20       ` Darren Hart
2014-07-21 17:20         ` Darren Hart
     [not found]     ` <CFF29A00.9D44A%dvhart@linux.intel.com>
     [not found]       ` <CFF29A00.9D44A%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-07-21 17:41         ` Darren Hart [this message]
2014-07-21 17:41           ` Darren Hart
     [not found]           ` <CFF29E4A.9D44E%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-07-21 20:16             ` Thomas Gleixner
2014-07-21 20:16               ` Thomas Gleixner
2014-07-21 21:27               ` Peter Zijlstra
2014-07-21 21:27                 ` Peter Zijlstra
2014-07-21 21:31                 ` Andy Lutomirski
2014-07-21 21:47                   ` Thomas Gleixner
2014-07-21 22:41                     ` Darren Hart
2014-07-22  1:01                       ` Thomas Gleixner
2014-07-22  1:34                         ` Steven Rostedt
2014-07-22  2:31                           ` Mike Galbraith
2014-07-22  3:06                           ` Davidlohr Bueso
     [not found]                           ` <20140721213457.46623e2f-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2014-07-22  7:47                             ` Peter Zijlstra
2014-07-22  7:47                               ` Peter Zijlstra
2014-07-22  8:39                               ` Thomas Gleixner
2014-07-22  8:39                                 ` Thomas Gleixner
2014-07-22  8:48                                 ` Peter Zijlstra
2014-07-22  9:59                                   ` Thomas Gleixner
2014-07-22  9:59                                     ` Thomas Gleixner
2014-07-22 20:25                                     ` Waiman Long
2014-07-22 20:52                                       ` Thomas Gleixner
2014-07-22 20:21                         ` Waiman Long
2014-07-22 21:03                           ` Thomas Gleixner
2014-07-22  0:32                   ` Davidlohr Bueso
2014-07-22  7:35                     ` Peter Zijlstra
2014-07-21 21:43                 ` Thomas Gleixner
2014-07-21 18:24     ` Thomas Gleixner
2014-07-22 18:35     ` Waiman Long
2014-07-22 18:28   ` Waiman Long
     [not found]   ` <8761iq3bp3.fsf-KWJ+5VKanrL29G5dvP0v1laTQe2KTcn/@public.gmane.org>
2014-07-23  4:55     ` Mike Galbraith
2014-07-23  4:55       ` Mike Galbraith
2014-07-23  6:57       ` Peter Zijlstra
2014-07-23  7:25         ` Mike Galbraith
2014-07-23  7:25           ` Mike Galbraith
2014-07-23  7:35           ` Peter Zijlstra
2014-07-23  7:39             ` Mike Galbraith
2014-07-23  7:39               ` Mike Galbraith
2014-07-23  7:52               ` Peter Zijlstra
2014-07-21 21:18 ` Ingo Molnar
2014-07-21 21:41   ` Thomas Gleixner
     [not found]   ` <20140721211801.GA12149-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-22 19:36     ` Waiman Long
2014-07-22 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=CFF29E4A.9D44E%dvhart@linux.intel.com \
    --to=dvhart-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=Waiman.Long-VXdhtT5mjnY@public.gmane.org \
    --cc=andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org \
    --cc=davidlohr-VXdhtT5mjnY@public.gmane.org \
    --cc=heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
    --cc=jason.low2-VXdhtT5mjnY@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=scott.norton-VXdhtT5mjnY@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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.