Re: status of NetBSD SMP support

To be clear: I know the kernel isn=E2=80=99t fully parallel ((S)MP) - =
otherwise the recent work on the networking stack (e.g. making ARP =
caches per interface) wouldn=E2=80=99t be necessary.

What I was looking for was a general status report of the NetBSD kernel =
(and userland) on SMP systems (more commonly known as =E2=80=9Cmulticore=E2=
=80=9D in au courant parlance): how multithreaded is it? How much lock =
contention? Is Big Lock gone - devolved into lots of small locks?

What=E2=80=99s the deal?

It=E2=80=99s one thing to boot and throw processes at cores (processors) =
- it=E2=80=99s another to have the kernel properly parallel so that when =
those processes make system calls, they don=E2=80=99t contend with each =
other (much).

All this in full cognizance of Amdahl=E2=80=99s Law and the non-parallel =
bits we can do nothing about (e.g. single I/O paths to sole devices). I =
just want to have some idea how much more parallelism we can pull out of =
the currently non-parallel code to reduce that serial time term in =
Amdahl=E2=80=99s Law to minimum, because the hardware guys are going to =
continue throw ever more cores at us for lack of any better idea of what =
to do with the chip area that Moore=E2=80=99s Law has given them (and =
us), and just as Amdahl predicted, that serial term will dominate as the =
core counts go up.

I bet the SIMD engines are going to get fancier, too. Just look at GPUs.

	Erik <[email protected]>


> On Aug 9, 2016, at 11:17, David Holland <[email protected]> =
wrote:
>=20
> On Mon, Aug 08, 2016 at 07:36:05PM -0400, Thor Lancelot Simon wrote:
>>> Last I remember anyone reporting hard results, the scaling worked to
>>> ~16 but not to ~32 and the uvm page queue lock was the chief =
culprit.
>>> Dunno what if anything's been done about that...
>>=20
>> There's a fragmentary discussion of it from around 2010 in the =
mailing list
>> archives, but something must have been done as that particular =
limitation
>> seems to have gone away.  Our build cluster nodes run happily with 12
>> cores, 24 threads, and I do not see the scaling issues we observed =
between
>> 16 and 20 cores in my tests years ago.
>=20
> In that case we definitely need someone to collect some hard numbers =
:-)
>=20
> --=20
> David A. Holland
> [email protected]