mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Khalid Aziz <khalid.aziz@oracle.com>,
	corbet@lwn.net, mingo@redhat.com, hpa@zytor.com,
	peterz@infradead.org, riel@redhat.com, akpm@linux-foundation.org,
	rientjes@google.com, ak@linux.intel.com, mgorman@suse.de,
	liwanp@linux.vnet.ibm.com, 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 v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace)
Date: Mon, 24 Nov 2014 18:12:39 -0800	[thread overview]
Message-ID: <1416881559.20575.14.camel@linux-t7sj.site> (raw)
In-Reply-To: <alpine.DEB.2.11.1411242317380.6439@nanos>

On Tue, 2014-11-25 at 00:35 +0100, Thomas Gleixner wrote:
> On Mon, 24 Nov 2014, Khalid Aziz wrote:
> > sched/fair: Add advisory flag for borrowing a timeslice
> > 
> > This patch adds a way for a task to request to borrow one timeslice
> > from future if it is about to be preempted, so it could delay
> > preemption and complete any critical task it is in the middle of.
> > 
> > This feature helps with performance on databases and has been
> > used for many years on other OSs by the databases. This feature
> > helps in situation where a task acquires a lock before performing a
> > critical operation on the database and happens to get preempted before
> > it completes its task.  This lock being held causes all other tasks
> > that also acquire the same lock to perform their critical operation
> > on the database, to start queueing up and causing large number of
> > context switches.  This queueing problem can be avoided if the task
> > that acquires lock first could request scheduler to let it borrow one
> > timeslice once it enters its critical section and hence allow it to
> > complete its critical section without causing queueing problem. If
> 
> While you are niftily avoiding to talk about the nature of the lock, I
> can take it for granted that you are talking about user space
> spinlocks, right?

Probably, or perhaps userspace fair locks. If the task that is next in
line to acquire the lock is preempted and the lock is released, fairness
prevents anyone else from taking it instead.

Thanks,
Davidlohr



  reply	other threads:[~2014-11-25  2:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 20:56 Khalid Aziz
2014-11-24 22:43 ` Andi Kleen
2014-11-24 23:20   ` Khalid Aziz
2014-11-24 23:35 ` Thomas Gleixner
2014-11-25  2:12   ` Davidlohr Bueso [this message]
2014-11-25  4:20   ` Mike Galbraith
2014-11-25 14:50     ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz
2014-11-25 17:46       ` Mike Galbraith
2014-11-25 19:38         ` Khalid Aziz
2014-11-25 14:45   ` Khalid Aziz
2014-11-25 18:27     ` Davidlohr Bueso
2014-11-25 19:23       ` Khalid Aziz
2014-11-25 19:40         ` Davidlohr Bueso
2014-11-25  2:03 ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace) Rik van Riel
2014-11-25  6:30   ` Davidlohr Bueso
2014-11-25 13:38     ` Rik van Riel
2014-11-25 14:52   ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz
2014-11-25 15:25     ` Rik van Riel
2014-11-25 17:22       ` Khalid Aziz
2014-11-25 17:45         ` Rik van Riel
2014-11-25 10:12 ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace) Srikar Dronamraju
2014-11-25 14:56   ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz

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=1416881559.20575.14.camel@linux-t7sj.site \
    --to=dave@stgolabs.net \
    --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=liwanp@linux.vnet.ibm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=riel@redhat.com \
    --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

all inboxes | Powered by JetHome®