ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.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: Tue, 14 Jul 2015 16:15:52 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1507141613500.12219@east.gentwo.org> (raw)
In-Reply-To: <CALCETrU1DjzUHDa_NrYPTaY7Zk0M2ehP4e74gPhV5GEYLJL0Og@mail.gmail.com>

On Tue, 14 Jul 2015, Andy Lutomirski wrote:

> Crazy thought: At the risk of proposing something ridiculous, what if
> we had per-cpu memory mappings?  We could do this at the cost of up to
> 2kB of memcpy whenever we switch mms.  Expensive but maybe not a
> showstopper.

This is not crazy and actually was done before. Itanium has that and
its doable since the TLB insertion could be handled in software.

The problem on x86 is that one would need a separate page table for each
processor for each task. There is no way to handle TLB faults in
software to my knowledge.

  reply	other threads:[~2015-07-14 21:15 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
2015-07-14 20:00         ` Andy Lutomirski
2015-07-14 21:15           ` Christoph Lameter [this message]
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.1507141613500.12219@east.gentwo.org \
    --to=cl@linux.com \
    --cc=axboe@fb.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --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