Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29737

Re: Page sizes

Show all headers | View raw

On 6/27/2020 10:01 PM, George Neuner wrote:
>>> If you want a *useful* segmenting MMU, you probably need to design it
>>> yourself.  Historically there were some units that did it (what I
>>> would call) right, but none are scalable to modern memory sizes.
>>>
>>> Whatever you do, you want the program to work with flat addresses and
>>> have segmentation applied transparently (like paging) during memory
>>> access.  You certainly DO NOT want to follow the x86 example of
>>> exposing segments in the addressing.
>>
>> Agreed.  Segments were meant to address a different problem.
>>
>> OTOH, exposing them to the instruction set removes any potential
>> ambiguity if two (or more) "general purpose" segments could
>> overlap at a particular spot in the address space; the opcode
>> acts as a disambiguator.
> 
> ???  Not following.

In a large, flat address space, it is conceivable that "general purpose"
segments could overlap.  So, in such an environment, an address presented
to the memory subsystem would have to resolve to SOME particular physical
address, "behind" the segment hardware.  The hardware would have to resolve
any possible ambiguities.  (how do you design the HARDWARE to prevent
ambiguities from arising without increasing its complexity even more??).

If, instead, the segments are exposed to the programmer, then the
choice of opcode determines which segment (hardware) is consulted
to resolve the reference(s).  Any "overlap" becomes unimportant.

>> The PMMU approach sidesteps this issue by rigidly defining where
>> (in the physical and virtual address spaces) a new page CAN begin.
>> It's bank-switching-on-steroids...
>>
>> [IIRC, I had previously concluded that variable sizes were impractical
>> for reasons like this]
> 
> The problem is that you're thinking only about the protection aspect
> ... it's the subdivision management of the address space that is made
> slow and difficult if you allow mapping arbitrarily sized regions.

Perhaps you missed:

    '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!'

You have N "modules" in a typical application.  The linkage editor mashes
them together into a single binary to be loaded, ensuring that they don't
overlap each other (d'uh!).  Easy-peasy.

You have the comparable problem with each segment representing a
discrete "object" being made to coexist disjointedly in a single
address space.

If the "objects" never change, over time, then this is no harder to
address than the linkage editor problem (assuming any segment can
being at any location and have any size).  Especially for PIC.

But, if segments can be added/removed/resized dynamically, then
you're essentially dealing with the same sort of fragmentation
problem that arises in heap management AND the same sort of
algorithm choices for selecting WHERE to create the next requested
segment (unless you pass that off to the application to handle
as IT knows what its current and future needs will be).

> You have to separate the concerns to do either one efficiently.
> 
> That's why pure segment-only MMUs quickly were superceded by
> combination page+segment units with segmenting relegated to protection
> while paging handled address space.  And now many CPUs don't even
> bother with segments any more.

The advantage that fixed size (even if there is a selection of sizes
to choose from) pages offers is each page has a particular location
into which it fits.  You don't have to worry that some *other* page
partially overlaps it or that it will overlap another.

But, with support for different (fixed) page sizes -- and attendant
performance consequences thereof -- the application needs to hint
the OS on how it plans/needs to use memory in order to make optimum
use of memory system bandwidth.  Silly for the OS to naively choose
a page size for a process based on some crude metric like "size of
object".  That can result in excessive resources being bound that
aren't *typically* USED by that object -- fault in those portions AS
they are needed (why do I need a -- potentially large -- portion of
the object residing in mapped memory if it is only accessed very
infrequently?)

OTOH, a finer-grained choice (allowing smaller pieces of the object
to be mapped at a time) reduces TLB reach as well as consuming OTHER
resources (e.g., TLB misses) for an object with poor locality of
reference (here-a-hit, there-a-hit, everywhere-a-hit-hit...)

So, there needs to be a conversation between the OS and the application
regarding how, best, to map the application onto the hardware -- with
"suitable" defaults in place for applications that aren't aware of
the significance of these issues.  This is particularly true if the
application binary can be hosted on different hardware -- or
MIGRATED to different hardware while executing!

Obviously makes sense to design that API in a way that is only as
general as it needs to be; WHY SUPPORT POSSIBILITIES THAT DON'T EXIST?
(Or, that aren't *likely* to exist in COTS hardware?)  IOW, you
can KNOW that:
     ASSERT( !( (pagesize - 1) & pagesize ) )
for all supported "pagesize", and code accordingly!

Paraphrasing:  "Make something as simple as it can be -- and no simpler"

[Time to check the daily briefing on the fire and then go out and take
a look at it...]

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-26 21:45 -0700
  Re: Page sizes Bernd Linsel <bl1@gmx.com> - 2020-06-27 08:33 +0200
    Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-27 00:32 -0700
      Re: Page sizes Bernd Linsel <bl1@gmx.com> - 2020-06-27 12:21 +0200
        Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-27 15:12 -0700
        Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-27 18:14 -0400
      Re: Page sizes David Brown <david.brown@hesbynett.no> - 2020-06-27 17:21 +0200
        Re: Page sizes Clifford Heath <no.spam@please.net> - 2020-06-28 15:30 +1000
      Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-27 18:02 -0400
  Re: Page sizes upsidedown@downunder.com - 2020-06-27 11:11 +0300
  Re: Page sizes John Speth <johnspeth@yahoo.com> - 2020-06-27 07:59 -0700
  Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-27 17:37 -0400
    Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-27 15:10 -0700
      Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-27 18:35 -0400
        Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-27 16:36 -0700
          Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-28 01:01 -0400
            Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-27 23:50 -0700
              Re: Page sizes upsidedown@downunder.com - 2020-06-28 13:27 +0300
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-28 11:49 -0700
              Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-30 00:05 -0400
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-29 23:24 -0700
                Re: Page sizes upsidedown@downunder.com - 2020-06-30 11:00 +0300
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-30 12:23 -0700
                Re: Page sizes upsidedown@downunder.com - 2020-07-01 13:31 +0300
                Re: Page sizes Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-01 19:44 +0300
                Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-30 05:45 -0400
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-30 04:13 -0700
                Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-06-30 12:49 -0400
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-30 12:44 -0700
                Re: Page sizes George Neuner <gneuner2@comcast.net> - 2020-07-02 03:14 -0400
        Re: Page sizes upsidedown@downunder.com - 2020-06-28 09:24 +0300
          Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-28 00:11 -0700
            Re: Page sizes upsidedown@downunder.com - 2020-06-28 15:59 +0300
              Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-28 12:04 -0700
                Re: Page sizes upsidedown@downunder.com - 2020-06-30 06:43 +0300
                Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-29 23:47 -0700
          Re: Page sizes Rick C <gnuarm.deletethisbit@gmail.com> - 2020-06-28 01:18 -0700
            Re: Page sizes upsidedown@downunder.com - 2020-06-28 16:29 +0300
              Re: Page sizes Don Y <blockedofcourse@foo.invalid> - 2020-06-28 12:18 -0700
  Re: Page sizes Richard Damon <Richard@Damon-Family.org> - 2020-06-27 18:27 -0400
  Re: Page sizes Andrew Smallshaw <andrews@sdf.org> - 2020-07-04 06:11 +0000

csiph-web