Public Discussions > General Discussion

QSINIT updated - now with HPFS support for the ramdisk

(1/2) > >>

rbri:
There is a new version available that supports hpfs-formated ramdisk.
Works without problems here.

Many thanks!

Michaelhz:
This is really great news. We can easily put swapper.dat on the ramdisk now. This is a great step forward.

Works perfect here.

Many thanks to Dmitry Zavalskov!

Michael

Doug Bissett:

--- Quote from: Michael Holzapfel on March 28, 2015, 10:30:53 am ---This is really great news. We can easily put swapper.dat on the ramdisk now. This is a great step forward.

Works perfect here.

Many thanks to Dmitry Zavalskov!

Michael

--- End quote ---

Many thanks indeed.

But why put the swap file on a RAMDISK? If you have enough memory to use a RAMDISK, you probably don't use the swap file anyway (I have never seen the swap file used when I have more than about 1.5 GB of memory). If you do need the swap file, you would be better off to not use a RAMDISK, and let the system use the memory. Putting %TEMP% on the RAMDISK makes sense.

Don't forget that running out of swap space can be deadly. It is best to have the swap file on the disk with the most free space, if you actually need a swap file.

I applaud the step forward, to use HPFS, but I also encourage one more step, to use JFS. I quit using the HPFS driver a few years ago (when it became possible to boot from JFS). The main reason was that it saves a good chunk of very scarce shared memory space. JFS also works better than HPFS (IMO). To use HPFS on the RAMDISK, I need to install the HPFS driver. That is not going to happen on my systems.

dbanet:
Doug, the author of QSINIT has reported that the support of formatting into JFS will not be introduced in QSINIT as being too hard and senseless, as there is no need for a journaling file system on a RAM drive.

Doug, what Michael meant by really great news was the ability to actually swap out to the physical memory, directly inaddressable by OS2KRNL, which theoretically means the ability to address more than four gibibytes of virtual memory in system.

Michael, that could be very good news, but unfortunately there is actually one another drawback in any existing OS2KRNL, no matter released by David or the Phoenix OS/4 project: it appears (please check out my signature) that there is a technical limitation of all memory allocated by all processes, i.e. swapped + not swapped memory. I've once run a test with 14.104a_SMP and the kernel being the latest released by Phoenix OS/4 back at that time: I've checked that swapping is turned on on my system, and that the drive where the SWAPPER.DAT file is located is big enough, and tried to allocate as much memory, as I could. I was spawning processes each allocating some fixed amount of memory, which I selected, but no matter what amount of memory each process allocated, its sum had never been greater than 4 GiB, because every time eventually I either got a system hang, or a malloc failure, or both. This was happening on both kernels.

I've said this is a technical limitation, because it actually seems to be just a single drawback in the current OS2KRNL implementation, as there is no theoretical limitation of the overall amount of memory allocated by all processes. I can't be sure (still please take my signature into consideration), but it seems to be a limit that is not that hard to overcome (means, way easier than to introduce direct PAE support in OS2KRNL). I really suggest the kernel developers to cooperate, share the code, and solve the actual problems...

Regards.

Doug Bissett:

--- Quote ---Doug, the author of QSINIT has reported that the support of formatting into JFS will not be introduced in QSINIT as being too hard and senseless, as there is no need for a journaling file system on a RAM drive.
--- End quote ---

Well, yes there is a need. If I load the HPFS driver, I constantly run into "insufficient memory" problems. Without it, I don't. The RAMDISK needs a file system that is better than FAT(32). I format the FAT32 drive to JFS during boot, and it works well. The tricky part is, that the file system somehow thinks that JFS does not properly support long file names, until I unmount the drive, and mount it again, after the GUI gets started (the procedure is somewhere on OS2WORLD).


--- Quote ---Doug, what Michael meant by really great news was the ability to actually swap out to the physical memory, directly inaddressable by OS2KRNL, which theoretically means the ability to address more than four gibibytes of virtual memory in system.
--- End quote ---

Hmmm. You read something into that, that I don't see. You cannot use more than 4 GB of memory directly. You could use the "extended" memory by paging it into/outof "main" memory. This is a totally different thing than using the swap file, and the kernel limit of 4 GB still exists. That doesn't mean that a program is actually limited by that, IF it knows how to use the"extended" memory. As I understand it, the RAMDISK support provides a framework for using "extended" memory, but there is no program interface for that, yet. A program would also need to be specifically written to use the "extended" memory (as the RAMDISK is). With some serious rework in the memory allocation area, it may be possible to dynamically use the "extended" memory, but I doubt if anybody has the knowledge to be able to do it (I would love to be proven wrong).

So, the kernel knows about private memory, and shared memory, for a total of 4 GB. Programs could be taught to use "extended" memory, that the kernel knows nothing about. That could be a little tricky if the system crashes, and somebody is trying to figure out a system dump, but that should not be a killer. I see "extended" memory being used exclusively for program data, so it doesn't matter if the kernel knows about it, or not. DOS has used a similar memory setup, for years, and DOS still only knows about 1 meg.

Navigation

[0] Message Index

[#] Next page

Go to full version