Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Tonight's tradeoff
Date: Thu, 7 Mar 2024 19:55:11 -0800
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <use270$1a5sl$1@dont-email.me>
References: <uis67u$fkj4$1@dont-email.me> <us3l9r$2vtrd$1@dont-email.me>
 <CxkFN.164321$JLvf.86786@fx44.iad> <us6dvv$3kp3g$1@dont-email.me>
 <95f07d18ea021f53af50c0bf2064ccdf@www.novabbs.org>
 <us7hu4$3qpum$1@dont-email.me>
 <6c40d0ff46f3a25f75d1bb7f28544532@www.novabbs.org>
 <usd69u$iq1t$1@dont-email.me> <MvpGN.404522$Ama9.235414@fx12.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 8 Mar 2024 03:55:12 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="c8ea9a2c373e9efd6b63ae25867acfca";
	logging-data="1382293"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+IJf0XT7TwGh3YHXN5aD8eskdgMCsn8No="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XzvhKhg1ETLm6OoTgsCUpryK/H0=
Content-Language: en-US
In-Reply-To: <MvpGN.404522$Ama9.235414@fx12.iad>
Bytes: 3202

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)