linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC/PATCH 2/2] powerpc: 44x doesn't need G set everywhere
Date: Thu, 11 Dec 2008 07:03:57 +1100	[thread overview]
Message-ID: <1228939437.22413.75.camel@pasglop> (raw)
In-Reply-To: <20081210083143.62b869f4@zod.rchland.ibm.com>


> > We still leave G=1 on the linear mapping for now, we need to
> > stop over-mapping RAM to be able to remove it.
> 
> Hm.  Over-mapping it has the nice advantage that we use as few pinned
> TLB entries as possible.  For 440x6 cores with more than 256 MiB of
> DRAM, you could theoretically use a single 1GiB TLB entry to map all
> kernel DRAM.

Ok well, there are several issues here.. see below

> Do you think the trade-offs of allowing speculative accesses are worth
> the increased TLB pressure?  Large base pages will help with that in
> some workloads, but others are still going to be TLB constrained.
> 
> I know, I'm probably paranoid.  But changing things like this around
> without some kind of benchmark data or testcase to make sure we aren't
> making it worse gives me the heebee-geebees.

Yup, which is why I'm not changing it yet :-) My initial thinking was
along the lines of: We can use up to 4 bolted TLB entries, that will
cover most classic memory configurations such as 256, 512 etc.... and
leave what doesn't fit to highmem.

However that fails miserably with 128M which is quite common.

Then I thought we could overmap and use G for things that don't quite
fit and remove G when we know we can do an exact mapping...

Then I though .. heh, first we know there is no speculative or
prefetched data access on 440. We also know that speculative /
prefetched instruction access is busted and must be disabled.

Thus can't we just both overmap and not have G ?

Needs testing of course :-) I'm waiting for an answer from the chip guys
here.

G=1 has some other impacts, such as preventing write combining I think,
re-ordering, and a few other things.

Cheers,
Ben.

  reply	other threads:[~2008-12-10 20:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10  5:50 [RFC/PATCH 2/2] powerpc: 44x doesn't need G set everywhere Benjamin Herrenschmidt
2008-12-10 13:31 ` Josh Boyer
2008-12-10 20:03   ` Benjamin Herrenschmidt [this message]
2008-12-10 20:11     ` Josh Boyer

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=1228939437.22413.75.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    /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).