linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Khalid Aziz <khalid.aziz@oracle.com>, Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	corbet@lwn.net, mingo@redhat.com, hpa@zytor.com,
	akpm@linux-foundation.org, rientjes@google.com,
	ak@linux.intel.com, mgorman@suse.de, raistlin@linux.it,
	kirill.shutemov@linux.intel.com, atomlin@redhat.com,
	avagin@openvz.org, gorcunov@openvz.org,
	serge.hallyn@canonical.com, athorlton@sgi.com, oleg@redhat.com,
	vdavydov@parallels.com, daeseok.youn@gmail.com,
	keescook@chromium.org, yangds.fnst@cn.fujitsu.com,
	sbauer@eng.utah.edu, vishnu.ps@samsung.com, axboe@fb.com,
	paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH RESEND v4] sched/fair: Add advisory flag for borrowing a timeslice
Date: Tue, 23 Dec 2014 13:46:58 -0500	[thread overview]
Message-ID: <5499B8A2.4080008@redhat.com> (raw)
In-Reply-To: <5499867C.1010201@oracle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/23/2014 10:13 AM, Khalid Aziz wrote:
> On 12/23/2014 03:52 AM, Ingo Molnar wrote:
>> 
>> 
>> to implement what Thomas suggested in the discussion: a proper 
>> futex like spin mechanism? That looks like a totally acceptable 
>> solution to me, without the disadvantages of your proposed 
>> solution.
> 
> Hi Ingo,
> 
> Thank you for taking the time to respond. It is indeed possible to 
> implement a futex like spin mechanism. Futex like mechanism will
> be clean and elegant. That is where I had started when I was given
> this problem to solve. Trouble I run into is the primary
> application I am looking at to help with this solution is Database
> which implements its own locking mechanism without using POSIX
> semaphore or futex. Since the locking is entirely in userspace,
> kernel has no clue when the userspace has acquired one of these
> locks. So I can see only two ways to solve this - find a solution
> in userspace entirely, or have userspace tell the kernel when it
> acquires one of these locks. I will spend more time on finding a
> way to solve it in userspace and see if I can find a way to 
> leverage futex mechanism without causing significant change to
> database code. There may be a way to use priority inheritance to
> avoid contention. Database performance people tell me that their
> testing has shown the cost of making any system calls in this code
> easily offsets any gains from optimizing for contention avoidance,
> so that is one big challenge. Database rewriting their locking code
> is extremely unlikely scenario. Am I missing a third option here?

An uncontended futex is taken without ever going into kernel
space. Adaptive spinning allows short duration futexes to be
taken without going into kernel space.

Only long held locks cause a thread to go into kernel space,
where it goes to sleep, freeing up the cpu, and increasing
the chance that the lock holder will run.

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUmbihAAoJEM553pKExN6DDlQH/1vvy9YYuP2dCAZSU3fz855e
pj4796Qja929I2dStsbLl6Qhcg2ELtwtPkLoAePQ/4j2l7DCYgSNLXlC+RzQ32ay
rbMIfwiriEVGp2hsvYTOCpnur19IHf7v726ivaDXVOM/nrRaHsB8wwspLQQyfSIE
b7M7jxvT4S2pEELOGB6JQfEZZhbf5wBv9HBk+fkCBMaO4WZrnYczyD0/omiADm65
xSm/8pCMK22u8Tzn9EpKpIVdIFrl9AlZ1uiRBV2Br1oqwaBTvJVknW4bvIk0DWZU
ErwR/073UYKpl+xce3nbnixH8FeRP7/mq73Xd8e+iCgn6Dtzr1tANsu27EigMZ0=
=WHb3
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-12-23 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 18:44 [PATCH RESEND v4] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz
2014-12-18 22:28 ` Peter Zijlstra
2014-12-18 22:42   ` Khalid Aziz
2014-12-18 23:02     ` Thomas Gleixner
2014-12-18 23:38       ` Khalid Aziz
2014-12-19  0:27         ` Thomas Gleixner
2014-12-19 21:43           ` Khalid Aziz
2014-12-19 23:57             ` Thomas Gleixner
2014-12-22 16:40               ` Khalid Aziz
     [not found]                 ` <5498498B.90703-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-23 10:52                   ` Ingo Molnar
2014-12-23 15:13                     ` Khalid Aziz
2014-12-23 18:46                       ` Rik van Riel [this message]
2014-12-23 20:47                         ` Khalid Aziz
     [not found]                           ` <5499D4D7.90109-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-23 22:33                             ` Rik van Riel
2015-01-13 11:25                         ` Peter Zijlstra

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=5499B8A2.4080008@redhat.com \
    --to=riel@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=athorlton@sgi.com \
    --cc=atomlin@redhat.com \
    --cc=avagin@openvz.org \
    --cc=axboe@fb.com \
    --cc=corbet@lwn.net \
    --cc=daeseok.youn@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=rientjes@google.com \
    --cc=sbauer@eng.utah.edu \
    --cc=serge.hallyn@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=vdavydov@parallels.com \
    --cc=vishnu.ps@samsung.com \
    --cc=yangds.fnst@cn.fujitsu.com \
    /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).