Re: NetBSD/vax vm for github testing

Johnny Billquist <[email protected]>
Newsgroups gmane.os.netbsd.ports.vax
Organization SoftJAR AB
Message-ID <[email protected]>
On 2025-01-11 15:29, John Klos wrote:
>> I wrote multiprocessor support for NetBSD/vax many years ago; but not 
>> many vax machines can
>> have multiple CPUs. It did work on VAX8250, which was just over one 
>> VUPS (which is extremely
>> slow today). Also, emulating multiprocessor support in general using a 
>> multiprocessor
>> machine is extremely difficult, since you need to synchronise the CPUs 
>> so that they emulate
>> at exactly the same speed. -- Ragge
> 
> Just curious: why would multiple CPUs need to emulate at exactly the 
> same speed? I've read about multiprocessor VAXen running different CPUs, 
> and I've run different CPUs on other architectures (Celery and Pentium 
> II with i386, SPARC and HyperSPARC on, well, sparc).
> 
> Were the people running different CPUs in a VAX doing something different?
> 
> BTW - someone modified SIMH to run multiple CPUs, but only supported 
> OpenVMS. The author had no interest in NetBSD.
> 
> https://oboguev.net/vax_mp/

Maybe half an answer. On the PDP-11 (which I know, didn't have MP), RSX 
is the only OS supporting multiprocessors. And there, there is the 
mechanism for waking up another CPU when work needs to be done on a 
specific CPU, and it is expected to respond within a certain time, or 
else the system will panic, assuming that the other CPU lost it somewhere.

Back in the day when the code was written, this is spinning in a right 
loop polling that the other CPU responded. And that tight loop is done 
for a certain number of iterations. Now, on a fast emulation, that loops 
spins through in no time, and a thread dealing with another CPU might 
not at all be able to respond in time unless there is a little bit of 
lockstep synchronization between the two threads/CPUs.
So, within some "reasonable" limits, the different CPUs need to run at 
some matching speeds, and also bursts. Since simulation happens in 
userspace, you get exposed to user process context switching and thread 
execution. So one CPU on such a simulated system might run for a time 
quanta before another CPU does a similar burst, which can be very 
non-functional to MP operations and mechanisms on the simulated system, 
which assumes that all CPUs are progressing at the same time.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.