From: Paul Mackerras <paulus@samba.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH -V3 11/11] arch/powerpc: Add 64TB support
Date: Mon, 23 Jul 2012 21:06:54 +1000 [thread overview]
Message-ID: <20120723110654.GC29264@bloggs.ozlabs.ibm.com> (raw)
In-Reply-To: <87txwyhj5e.fsf@skywalker.in.ibm.com>
On Mon, Jul 23, 2012 at 03:52:05PM +0530, Aneesh Kumar K.V wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
> >
> >> -#define USER_ESID_BITS 16
> >> -#define USER_ESID_BITS_1T 4
> >> +#define USER_ESID_BITS 18
> >> +#define USER_ESID_BITS_1T 6
> >
> > You also need to change the proto-VSID generation for kernel addresses
> > when you do this. If you don't you'll end up with some user processes
> > using the same VSIDs as we use for the kernel addresses, meaning that
> > those processes won't run very well...
> >
>
> Can you explain this more. right now we generate vsid as below
>
> vsid_scramble(ea >> SID_SHIFT, 256M) for kernel
>
> vsid_scramble((context << USER_ESID_BITS) | (ea >> SID_SHIFT), 256M);
> for user
>
> what changes are you suggesting ?
Think about it. With the current values of USER_ESID_BITS and
CONTEXT_BITS, and the addresses we use for kernel mappings, there are
no values of context, user_ea and kernel_ea for which
kernel_ea >> SID_SHIFT == (context << USER_ESID_BITS) | (user_ea >> SID_SHIFT)
If you increase USER_ESID_BITS, then there will be some context values
for which that equation becomes true. For example, if you increase
USER_ESID_BITS to 18, then context 0x30000 will generate the same
proto-VSIDs as the kernel linear mapping. Since we can hand out
contexts up to 0x7ffff (with CONTEXT_BITS = 19), there is a collision.
In other words, the proto-VSID space (the space of values that are
input to vsid_scramble) is currently divided into two mutually
exclusive regions: from 0 to 2^35 - 1 for user processes, and from
2^35 to 2^36 - 1 for kernel addresses. You are wanting to expand the
amount of proto-VSID space that user processes can use, but you need
either to move the kernel portion of the space, or to make sure that
the context allocator doesn't hand out context values that would
collide with the kernel portion of the space (or both).
Paul.
next prev parent reply other threads:[~2012-07-23 11:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 13:13 [PATCH -V3 0/11] arch/powerpc: Add 64TB support to ppc64 Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 01/11] arch/powerpc: Use hpt_va to compute virtual address Aneesh Kumar K.V
2012-07-22 23:17 ` Paul Mackerras
2012-07-09 13:13 ` [PATCH -V3 02/11] arch/powerpc: Simplify hpte_decode Aneesh Kumar K.V
2012-07-22 23:26 ` Paul Mackerras
2012-07-23 5:41 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn Aneesh Kumar K.V
2012-07-09 22:41 ` Stephen Rothwell
2012-07-10 6:12 ` Aneesh Kumar K.V
2012-07-09 23:06 ` Stephen Rothwell
2012-07-10 6:15 ` Aneesh Kumar K.V
2012-07-22 23:42 ` Paul Mackerras
2012-07-23 5:54 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 04/11] arch/powerpc: Rename va " Aneesh Kumar K.V
2012-07-22 23:46 ` Paul Mackerras
2012-07-23 6:14 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate Aneesh Kumar K.V
2012-07-22 23:56 ` Paul Mackerras
2012-07-23 1:22 ` Benjamin Herrenschmidt
2012-07-23 3:49 ` Paul Mackerras
2012-07-23 6:44 ` Aneesh Kumar K.V
2012-07-23 6:48 ` Benjamin Herrenschmidt
2012-07-09 13:13 ` [PATCH -V3 06/11] arch/powerpc: Make KERN_VIRT_SIZE not dependend on PGTABLE_RANGE Aneesh Kumar K.V
2012-07-22 23:57 ` Paul Mackerras
2012-07-09 13:13 ` [PATCH -V3 07/11] arch/powerpc: Increase the slice range to 64TB Aneesh Kumar K.V
2012-07-23 0:00 ` Paul Mackerras
2012-07-23 7:13 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 08/11] arch/powerpc: Make some of the PGTABLE_RANGE dependency explicit Aneesh Kumar K.V
2012-07-23 0:20 ` Paul Mackerras
2012-07-23 7:29 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 09/11] arch/powerpc: Use 50 bits of VSID in slbmte Aneesh Kumar K.V
2012-07-23 0:06 ` Paul Mackerras
2012-07-23 8:21 ` Aneesh Kumar K.V
2012-07-23 9:36 ` Paul Mackerras
2012-07-23 10:22 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 10/11] arch/powerpc: Use 32bit array for slb cache Aneesh Kumar K.V
2012-07-23 0:27 ` Paul Mackerras
2012-07-23 8:25 ` Aneesh Kumar K.V
2012-07-09 13:13 ` [PATCH -V3 11/11] arch/powerpc: Add 64TB support Aneesh Kumar K.V
2012-07-23 0:15 ` Paul Mackerras
2012-07-23 8:49 ` Aneesh Kumar K.V
2012-07-23 9:39 ` Paul Mackerras
2012-07-23 10:22 ` Aneesh Kumar K.V
2012-07-23 11:06 ` Paul Mackerras [this message]
2012-07-24 8:37 ` Aneesh Kumar K.V
2012-07-24 9:14 ` Aneesh Kumar K.V
2012-07-24 19:50 ` Aneesh Kumar K.V
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=20120723110654.GC29264@bloggs.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.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).