Yes. It's called "locking" or "pinning" the memory pages. It's not used often anymore before it means pages are stuck in their position and could cause fragmentation, which could slow the system overall when it needs to defrag memory in order to find large sequential chunks. Most of that logic is not needed anymore once since the large virtual tables are now present, and that's one thing that made the 386 popular.
Technically, there is "fast" and "slow" memory, but it is also known as ROM and RAM, and that being ROM is usually at least twice as fast RAM. Pre-386 machines, like Motorola based, put their system OS in ROM to boost its speed 8 times. That is how the Amiga, with its blitter hardware, did graphics manipulation way ahead of its time. Remember when Amiga used to be called a Game machine and Windows was "business" only, and now look at DX10 and the whole underlying market of ROM based video cards for Windows. You wonder where they got their ideas. *wink* Anyways, there still is some mixup in these related threads about script memory being split between avatar memory limits and parcel memory limits. When an avatar that has paid premium rates to be fashionable (hence, not a griefer at all) and the outfit require an expected XX amount of memory to runs its scripts... wanders onto a parcel that has had its memory limits choked... poo poo is gonna hit the fan. *tap* *tap* *tap* There are many people pay top dollar for their fashions in the real world, and obviously they won't go places that won't support their outfit. Do we need to actually make a case how this applies in-world? Parcel limits should not limit the avatar. (I know someone is gonna argue griefer cases, but bottom line... griefer objects are not avatar.) Stickman wrote: >> That's not how demand-paged virtual memory works. >> > > Is it possible to make a system that does? > > I kinda like the idea. It's basically what we have now, except with a > smart system that decides what swaps and what uses RAM. > > -Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
