ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@fb.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Shaohua Li <shli@fb.com>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences
Date: Mon, 13 Jul 2015 09:01:23 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1507130849450.18904@east.gentwo.org> (raw)
In-Reply-To: <20150713095757.GW19282@twins.programming.kicks-ass.net>

On Mon, 13 Jul 2015, Peter Zijlstra wrote:

> Now the 'problem' is finding these special regions fast, the easy
> solution is the same as the one proposed for userspace, one big section.
> That way the interrupt only has to check if the IP is inside this
> section which is minimal effort.
>
> The down side is that all percpu ops would then end up being full
> function calls. Which on some archs is indeed faster than disabling
> interrupts, but not by much I'm afraid.

Well one could move the entire functions that are using these ops into the
special sections. That is certainly an area requiring much more thought.

> > optimize the x86 variants if interrupts also can detect critical sections
> > and restart at defined points.
>
> I really don't see how we can beat %GS prefixes with any such scheme.

We may be able to avoid RMV sequences which allows the processor to better
schedule operations.

  reply	other threads:[~2015-07-13 14:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 18:32 Andy Lutomirski
2015-07-09 19:09 ` Chris Mason
2015-07-10 17:26   ` Christoph Lameter
2015-07-13  9:57     ` Peter Zijlstra
2015-07-13 14:01       ` Christoph Lameter [this message]
2015-07-14 20:00         ` Andy Lutomirski
2015-07-14 21:15           ` Christoph Lameter
2015-07-22 14:22       ` Lai Jiangshan
2015-07-22 14:34       ` Lai Jiangshan
2015-07-22 14:03   ` Lai Jiangshan

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=alpine.DEB.2.11.1507130849450.18904@east.gentwo.org \
    --to=cl@linux.com \
    --cc=axboe@fb.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=peterz@infradead.org \
    --cc=shli@fb.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