All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: <aleksey.makarov@auriga.com>, <james.hogan@imgtec.com>,
	<paul.burton@imgtec.com>, <david.daney@cavium.com>,
	<peterz@infradead.org>, <linux-mips@linux-mips.org>,
	<linux-kernel@vger.kernel.org>, <ralf@linux-mips.org>,
	<davidlohr@hp.com>, <kirill@shutemov.name>,
	<akpm@linux-foundation.org>, <mingo@kernel.org>
Subject: Re: [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS
Date: Fri, 15 May 2015 14:01:52 -0700	[thread overview]
Message-ID: <55565EC0.9030102@imgtec.com> (raw)
In-Reply-To: <55565BDF.6050503@gmail.com>

On 05/15/2015 01:49 PM, David Daney wrote:
> On 05/14/2015 06:34 PM, Leonid Yegoshin wrote:
>> SEGBITS default is 40 bits or less, depending from CPU type.
>> This patch introduces 48bits of application virtual address (SEGBITS) 
>> support.
>> It is defined only for 16K and 64K pages and is optional (configurable).
>>
>> Penalty - a small number of additional pages for generic (small) 
>> applications.
>> But for 64K pages it adds 3rd level of PTE structure, which has a little
>> impact during software TLB refill.
>>
>> This patch is needed because MIPS I6XXX and P6XXX cores have 48 bit of
>> virtual address in each segment (SEGBITS).
>>
>
> Those processors don't require the patch.  You wrote the patch to give 
> a larger VA space at the request of kernel users.  So perhaps say:
>
>   The patch (optionally) increases the VA space available to userspace 
> processes from N-bits to 48-bits
>

... if CPU model supports that

>
>>
>> +config 48VMBITS
>
> Should probabaly be called VABITS instead of VMBITS to match the terms 
> used in the architecture reference manuals, as well as other ports 
> (ARM64).
>
> Perhaps MIPS_VA_BITS_48

I don't mind here. It can be even called 48SEGBITS or so, to match arch 
manual more. MIPS Arch manual never says about VA bits but speaks about 
PABITS and SEGBITS.

- Leonid.

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: aleksey.makarov@auriga.com, james.hogan@imgtec.com,
	paul.burton@imgtec.com, david.daney@cavium.com,
	peterz@infradead.org, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	davidlohr@hp.com, kirill@shutemov.name,
	akpm@linux-foundation.org, mingo@kernel.org
Subject: Re: [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS
Date: Fri, 15 May 2015 14:01:52 -0700	[thread overview]
Message-ID: <55565EC0.9030102@imgtec.com> (raw)
Message-ID: <20150515210152.emUtHcT-z94W9bg7Bc9NfNsKfnuM1eLNRuR42PvU6xg@z> (raw)
In-Reply-To: <55565BDF.6050503@gmail.com>

On 05/15/2015 01:49 PM, David Daney wrote:
> On 05/14/2015 06:34 PM, Leonid Yegoshin wrote:
>> SEGBITS default is 40 bits or less, depending from CPU type.
>> This patch introduces 48bits of application virtual address (SEGBITS) 
>> support.
>> It is defined only for 16K and 64K pages and is optional (configurable).
>>
>> Penalty - a small number of additional pages for generic (small) 
>> applications.
>> But for 64K pages it adds 3rd level of PTE structure, which has a little
>> impact during software TLB refill.
>>
>> This patch is needed because MIPS I6XXX and P6XXX cores have 48 bit of
>> virtual address in each segment (SEGBITS).
>>
>
> Those processors don't require the patch.  You wrote the patch to give 
> a larger VA space at the request of kernel users.  So perhaps say:
>
>   The patch (optionally) increases the VA space available to userspace 
> processes from N-bits to 48-bits
>

... if CPU model supports that

>
>>
>> +config 48VMBITS
>
> Should probabaly be called VABITS instead of VMBITS to match the terms 
> used in the architecture reference manuals, as well as other ports 
> (ARM64).
>
> Perhaps MIPS_VA_BITS_48

I don't mind here. It can be even called 48SEGBITS or so, to match arch 
manual more. MIPS Arch manual never says about VA bits but speaks about 
PABITS and SEGBITS.

- Leonid.

  reply	other threads:[~2015-05-15 21:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15  1:34 [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS Leonid Yegoshin
2015-05-15  1:34 ` Leonid Yegoshin
2015-05-15 10:39 ` Sergei Shtylyov
2015-05-15 16:28 ` David Daney
2015-05-15 19:03   ` Leonid Yegoshin
2015-05-16  2:11     ` Maciej W. Rozycki
2015-05-15 20:49 ` David Daney
2015-05-15 21:01   ` Leonid Yegoshin [this message]
2015-05-15 21:01     ` Leonid Yegoshin
2015-05-15 21:53 ` Ralf Baechle
2015-05-15 22:39   ` Leonid Yegoshin
2015-05-15 22:39     ` Leonid Yegoshin
2015-05-16  2:42     ` Joshua Kinard

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=55565EC0.9030102@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=akpm@linux-foundation.org \
    --cc=aleksey.makarov@auriga.com \
    --cc=david.daney@cavium.com \
    --cc=davidlohr@hp.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=james.hogan@imgtec.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mingo@kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=peterz@infradead.org \
    --cc=ralf@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.