linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	Anton Blanchard <anton@samba.org>
Subject: Re: [RFC][PATCH] powerpc/64s: Leave IRQs hard enabled over context switch
Date: Wed, 03 May 2017 18:24:29 +0200	[thread overview]
Message-ID: <1493828669.25766.358.camel@kernel.crashing.org> (raw)
In-Reply-To: <87k25yutfw.fsf@concordia.ellerman.id.au>

On Wed, 2017-05-03 at 20:26 +1000, Michael Ellerman wrote:
> Couldn't we avoid the whole problem by just having two bolted slots for
> the stack, meaning we could have the current and next stack bolted at
> all times.
> 
> That would mean we'd be using 4 slots for bolted entries, which is one
> more than 3 - but it might be a good trade off.
> 
> Or we could make the SLB insertion algorithm smarter so that we could
> later free the slot that was used for previous kernel stack.

Changing the insertion algo is a bit nasty, it's nice and simple as-is,
an option would be to replace the bolted "threshold" by a bolted "map"
with a bit (or a byte) per entry.

Sadly, we have no way that I know of to search an slb entry that tells
you in which slot it is, do we ? So even if the "new" stack is already
somewhere in there, we can't know it and just "mark it bolted". We'd
still have to invalidate just in case before bolting it in.

Ben.

      reply	other threads:[~2017-05-03 16:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03  7:34 [RFC][PATCH] powerpc/64s: Leave IRQs hard enabled over context switch Nicholas Piggin
2017-05-03  8:28 ` Benjamin Herrenschmidt
2017-05-03  9:17   ` Nicholas Piggin
2017-05-03 10:26   ` Michael Ellerman
2017-05-03 16:24     ` Benjamin Herrenschmidt [this message]

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=1493828669.25766.358.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=anton@samba.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.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).