Forums

Page sizes

Started by Don Y June 27, 2020
Are there any processors/PMMUs for which the following would be true (nonzero)?

(pagesize - 1) & pagesize
On 27.06.2020 06:45, Don Y wrote:
> Are there any processors/PMMUs for which the following would be true > (nonzero)? > > (pagesize - 1) & pagesize
That would imply that the page size is not an integral power of 2. Very unlikely. Regards -- Bernd
On 6/26/2020 11:33 PM, Bernd Linsel wrote:
> On 27.06.2020 06:45, Don Y wrote: >> Are there any processors/PMMUs for which the following would be true (nonzero)? >> >> (pagesize - 1) & pagesize > > That would imply that the page size is not an integral power of 2.
Yes, that was the point of the question.
> Very unlikely.
As, for my needs, this is one of those "fundamental assumptions", I'm looking for more assurance than "very unlikely" -- just as one wouldn't pick one SPECIFIC page size and assume it to be ubiquitous (or even expecting a single page size to be supported at any given instant) :> But, I don't see any VALUE in other sizes as it needlessly complicates any *hardware* implementation (though poses little barrier to a software implementation!)
On Fri, 26 Jun 2020 21:45:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>Are there any processors/PMMUs for which the following would be true (nonzero)? > >(pagesize - 1) & pagesize
On a decimal (BCD) computer, the page size might have been 10 or 100 words. However, I much doubt that these ancient computer had MMU hardware,
On 27.06.2020 09:32, Don Y wrote:
> On 6/26/2020 11:33 PM, Bernd Linsel wrote: > > Yes, that was the point of the question. > > > As, for my needs, this is one of those "fundamental assumptions", I'm > looking for more assurance than "very unlikely" -- just as one wouldn't > pick one SPECIFIC page size and assume it to be ubiquitous (or even > expecting a single page size to be supported at any given instant)&nbsp; :> > > But, I don't see any VALUE in other sizes as it needlessly complicates > any *hardware* implementation (though poses little barrier to a software > implementation!)
Commonly (in all current mainstream processor architectures like iA32, AMD64, ARM, MIPS etc.) a MMU divides a logical address at bit boundaries into a page address and an offset. As a result, the page address on these platforms is always a power of two. Yes, there _may_ exist some exotic MMUs that let you choose protection areas (to avoid the term 'pages') with arbitrary base addresses and sizes. This flexibility requires heavily increased hardware efforts and cost and complicates an OS's memory management, so it's unlikely to be used at all. One example were the i286/i386's Protected Mode segments, but even there was a granularity of 4K/1M, so the assertion 'segment base address is a power of two' was also true, you just couldn't be sure each segment had the same size. Setting up and maintaining the segment descriptor tables was so complicated that mainstream OS's on i386 (NT, Linux) only set up the most necessary segments and went on using a flat 4GB address space and the page tables of the additional MMU. Furthermore, using segments slowed down hardware memory accesses considerably, that in the '486 and successors added Segment Descriptor Caches etc etc. Conclusion: No, you cannot fundamentally assume that page sizes on any existing MMU are powers of two. Hardware designers can implement whatever weird and complicated adressing patterns they like.
On 6/26/2020 9:45 PM, Don Y wrote:
 > Are there any processors/PMMUs for which the following would be true
 > (nonzero)?
 >
 > (pagesize - 1) & pagesize

I'm curious why it's important to you. A nice binary round number is 
easy to work with on the programming side and simplifies the silicon 
design side.

JJS
On 27/06/2020 09:32, Don Y wrote:
> On 6/26/2020 11:33 PM, Bernd Linsel wrote: >> On 27.06.2020 06:45, Don Y wrote: >>> Are there any processors/PMMUs for which the following would be true >>> (nonzero)? >>> >>> (pagesize - 1) & pagesize >> >> That would imply that the page size is not an integral power of 2. > > Yes, that was the point of the question.
If that was the point, why didn't you write that? Writing a C expression like that is appropriate if you are writing C code, but it would make more sense to write what you mean - and /why/ you are asking.
> >> Very unlikely. > > As, for my needs, this is one of those "fundamental assumptions", I'm > looking for more assurance than "very unlikely" -- just as one wouldn't > pick one SPECIFIC page size and assume it to be ubiquitous (or even > expecting a single page size to be supported at any given instant)&nbsp; :>
You might conceivably get an answer "this cpu has non-power-of-two page sizes". But you'll never get anything better than "very unlikely" the other way. You can't expect anyone (or even a combination of people) in this newsgroup to have used /every/ cpu design ever made, or that ever will be made. If you say why you think page sizes are relevant, however, then it's conceivable that people could give you more useful answers.
> > But, I don't see any VALUE in other sizes as it needlessly complicates > any *hardware* implementation (though poses little barrier to a software > implementation!)
Hi Don,


On Fri, 26 Jun 2020 21:45:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>Are there any processors/PMMUs for which the following would be >true (nonzero)? > >(pagesize - 1) & pagesize
Not anything you can buy. George
On Sat, 27 Jun 2020 00:32:00 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 6/26/2020 11:33 PM, Bernd Linsel wrote: >> On 27.06.2020 06:45, Don Y wrote: >>> Are there any processors/PMMUs for which the following would be true (nonzero)? >>> >>> (pagesize - 1) & pagesize >> >> That would imply that the page size is not an integral power of 2. > >Yes, that was the point of the question. > >> Very unlikely. > >As, for my needs, this is one of those "fundamental assumptions", I'm >looking for more assurance than "very unlikely" -- just as one wouldn't >pick one SPECIFIC page size and assume it to be ubiquitous (or even >expecting a single page size to be supported at any given instant) :> > >But, I don't see any VALUE in other sizes as it needlessly complicates >any *hardware* implementation (though poses little barrier to a software >implementation!)
Power-of-2 pages are ubiquitous in available hardware. 4KB is directly supported by almost all CPUs. Some allow smaller pages, many allow larger pages, but (excepting Alpha and UltraSparc) it's hard to find something that can't work with 4KB (perhaps by combining smaller pages). https://en.wikipedia.org/wiki/Page_(computer_memory)#Multiple_page_sizes https://en.wikipedia.org/wiki/Memory_management_unit#Examples George
Hi George,

Hope you are keeping well...  bad pandemic response, here; really
high temperatures; increasing humidity; and lots of smoke in the
air (but really cool "displays" at night!)  :<   Time to make some
ice cream and enjoy the ride!  :>

On 6/27/2020 2:37 PM, George Neuner wrote:
> Hi Don, > On Fri, 26 Jun 2020 21:45:54 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> Are there any processors/PMMUs for which the following would be >> true (nonzero)? >> >> (pagesize - 1) & pagesize > > Not anything you can buy.
I'm wondering if some of the "classic" designs might scale to newer device geometries better than some of the newer architectures? E.g., supporting ~100 (variable sized) segments concurrently and binding each to a particular "object" (for want of a better word). If the segment management hardware automatically reloads (in a manner similar to the TLBs functionality), then this should yield better (or comparable) performance to the fixed page-size approach (if you assume the fixed pages poorly "fit" the types of "objects" that you are mapping) [I think we discussed this -- or something similar -- a while ago] You still have a "packing problem" but with a virtual address space per process, you'd only have to address the "objects" with which a particular process interacted in any particular address space. And, that binding (for PIC) could be done at compile time *or* load time (the latter being more flexible) -- or even RUN-time!