Re: Tonight's tradeoff

On 3/7/2024 12:32 PM, Scott Lurndal wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 3/5/2024 9:32 AM, MitchAlsup1 wrote:
>
snip
>

I also believe in the tension between pages that are too small and those
that are too large. 256B is widely seen as too small (VAX). I think most
people are comfortable in the 4KB range. I think 64KB is too big since
something like cat needs less code, less data, and less stack space than
1 single 64KB page and another 64KB page to map cat from its VAS. So, now;
instead of four* 4KB pages (16KB ={code, data, stack, map} ) we now need
four 64KB pages 256KB. It is these small applications that drive the
minimum page size down.

>
In thinking about this, an idea occurred to me that may ease this
tension some.  For a large page, you introduce a new protection mode
such that, for example, the lower half of the addresses in the page are
execute only, and the upper half are read/write enabled.  This would
allow the code and the data, and perhaps even the stack for such a
program to share a single page, while still maintaining the required
access protection.  I think the hardware to implement this is pretty
small.  While the benefits of this would be modest, if such "small
programs" occur often enough it may be worth the modest cost of the
additional hardware.

 The biggest problem with variable page sizes isn't the hardware.

What I proposed is not variable page sizes.  All pages are the same size.  This idea is to add a new protection option within the same page.   The new option will allow "mixing" the code and data for a small program within the same page without sacrificing the protection that normaly requires multiple pages.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)