On 24/10/2022 20:27, J Booth wrote:
> On Monday, October 24, 2022 at 2:40:22 AM UTC-4, Alain Knaff wrote:
>>> Kernel VM = 38_00_00 – 3F_FF_FF (512 KB)
>> That bit I didn't know yet. As far as I know, Linux does the same (i.e.
>> the kernel exists in the application's address space, even though
>> inaccessible to the application, obviously)
> Ahh ok, I wasn't sure what that Kernel VM address space was.
However, at a second glance, I'm wondering about this now. In-Kernel
addresses are much lower that 0x380000. Indeed everything seems to be
below 0x20500 (you can apply nm to /UNIX3.51m to check). Unless it's
about kmalloc'ed dynamic memory.
>> Actually, the problem that I used to have was running "many" *processes*
> You've probably already found, but there is ktune which allows you to adjust some kernel parameters, such as nproc (number of processes, default: 100), e.g. ktune nproc=200
Actually, I haven't known about this yet, thanks for the pointer. So far
I had resorted to using a hex editor for this kind of stuff :-)
ktune sounds easier, at least for those variables that are available
swapdev does not seem to be available unfortunately. However, with the
hexeditor, I managed to set the swapdev variable at 0x1ed64 (0x1ee0c in
the UNIX3.51m file) to 0x11, and could swap from the second disk that
way. Given that on a second disk there are no longer any concerns of
pushing the root partition with the kernel image too far out, I managed
to set up a swap partition of 184M (beyond, the disk would be full).
mapmem did indeed show the full 44334 blocks, and I managed to spawn 69
instances of my 2.5M test process :-)
> But it sounds like that's not the issue, just purely running out of memory.
>> Adding more swap resolved the issue.
> Interesting to hear that helped. I would have thought the default 4000 KB would have sufficed, unless yours was smaller than that.
>> Next challenge is to get gcc-3.3.6 (running on UnixPC) to compile a
>> program longer than a simple hello-world. It runs out of memory pretty
>> quickly, and as this is one process, swap does not help that use case.
> Good luck!
> I really appreciate the work you and Mike have done on the cross compiler. A great resource for anyone interested in UNIX PC.
It's a pleasure to hear that you like it, thanks :-)