Sujet : Re: Tonight's tradeoff
De : sfuld (at) *nospam* alumni.cmu.edu.invalid (Stephen Fuld)
Groupes : comp.archDate : 10. Mar 2024, 06:34:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <usjgpf$2ej1u$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla Thunderbird
On 3/7/2024 9:13 PM, Robert Finch wrote:
On 2024-03-07 2:58 p.m., Stephen Fuld wrote:
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.
>
>
I had thoughts along this line too. I have added user access rights for each 1/4 of a page. Only a single 64kB page split in four is needed for a small app then.
Yes, similar. I suspect your solution is more general than mine and thus handles more cases, but requires more hardware, especially bits in the PTE. It's all a tradeoff.
-- - Stephen Fuld(e-mail address disguised to prevent spam)