bb@wjh12.UUCP (brent e byer) (11/29/85)
The ramdisk driver described worked by allocating its space
at BOOT time which makes it easy to implement but much less
useful than one which could do so dynamically, say, at XXXopen()
time.
Consider: You very well may need all the RAM you've got during
prime time, but when the `cheese' are away and just you &
I are there to play, we should not have to re-boot just
to get that silicon amphet. Also, there may come a time
during normals' hours when something MUST finish more
quickly.
To Kernel-Hacks: With price of ram plummeting, all of you should
cobble up something of this sort for your next release.
Your sales hacks may be able to sell more add-on memory
(iff they stop being so damn greedy with the price$ !!!),
[ and, we nightfolk may actually see our processes finish
before dawn. ]
PS: All programs which need /tmp-type space should check for
an ENV variable to allow better use of this new feature.
PPS: When you do the allocation, PLS take it off the top; yes,
shuffle if you need to.
Thanks,
Brent Byer {decvax!genrad harvard}!wjh12!bb
ihnp4!ihesa!textware!brentkeith@motel6.UUCP (Keith Packard) (12/02/85)
In article <658@wjh12.UUCP> bb@wjh12.UUCP (brent e byer) writes: >The ramdisk driver described worked by allocating its space >at BOOT time which makes it easy to implement but much less >useful than one which could do so dynamically, say, at XXXopen() >time. > >Consider: You very well may need all the RAM you've got during > prime time, but when the `cheese' are away and just you & > I are there to play, we should not have to re-boot just > to get that silicon amphet. Also, there may come a time > during normals' hours when something MUST finish more > quickly. > >Thanks, > Brent Byer {decvax!genrad harvard}!wjh12!bb > ihnp4!ihesa!textware!brent Actually, when I wrote the ramdisk driver, all I could think of was how nice it would be to have version 8 unix running. Then I could design my *own* filesystem structure - completely dynamic with disk backing store. If I also cobbled up the memory allocation routines to always return 1k chunks, I could use up *all* of memory with temporary file space. And have enough tmp space, even when memory was tight. The best fix to the current allocation scheme is to have a process do a system call, requesting that an appropriate amount of memory be set aside for the ramdisk. Then, the process would hang; waiting for the scheduler to swap enough processes out to make room for the ram disk. This would be similar to the current method for sbrk, but the memory would be allocated to the system and not freed until another ramdisk allocation was issued. This is, perhaps, the best way. The major reasons this was not done is that it requires major modifications to the scheduler and the addition of yasc (yet another system call). In other words, I didn't have the time to invest in it. It should also be fixed so that the raw device works correctly. This is quite possible as a routine already exists that will copy bytes from any address to any address - unfortunately it is rather broken in my version of 2.9 because it was a part of the networking code that was distributed in a non-working state. In Keith Bostic's distribution I expect that this routine is fixed. Keith Packard tektronix!reed!motel6!keith