Re: status of NetBSD SMP support

Hello!
Like Bartosz, I would like to add another question: about scalability and =
multi-core hardware, what is the state of NetBSD with respect to - for exam=
ple - Solaris?
Being specifically designed to run also with the SPARC architecture, maybe=
 Oracle Solaris fits very well in a multi-core environment and it is able t=
o efficiently divide its workload between the cores=2E Is NetBSD able to do=
 the same? If not, would NetBSD need to do the same?
Cheers :)

Rocky


> Sent: Wednesday, August 10, 2016 at 10:35 AM
> From: "Bartosz Marcinkiewicz" <bartoszmarc@gmail=2Ecom>
> To: "Erik Fair" <fair@netbsd=2Eorg>, "David Holland" <dholland-tech@netb=
sd=2Eorg>
> Cc: "Thor Lancelot Simon" <tls@panix=2Ecom>, "Cherry G=2E Mathew" <cherr=
y=2Eg=2Emathew@gmail=2Ecom>, "NetBSD Symmetric Multi-Processing" <tech-smp@=
netbsd=2Eorg>
> Subject: Re: status of NetBSD SMP support
>
> Hi,
>=20
> Pardon me for jumping in, but I have similar question, from a little=20
> different angle: what areas of the NetBSD kernel can be improved so they=
=20
> scale better on SMP machines, what can be implemented / researched?
>=20
> BR, bm=2E
>=20
>=20
> On 10/08/16 05:16, Erik Fair wrote:
> > To be clear: I know the kernel isn=E2=80=99t fully parallel ((S)MP) - =
otherwise the recent work on the networking stack (e=2Eg=2E making ARP cach=
es per interface) wouldn=E2=80=99t be necessary=2E
> >
> > What I was looking for was a general status report of the NetBSD kerne=
l (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 c=
ontention? 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 (processor=
s) - 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 ot=
her (much)=2E
> >
> > All this in full cognizance of Amdahl=E2=80=99s Law and the non-parall=
el bits we can do nothing about (e=2Eg=2E single I/O paths to sole devices)=
=2E 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 Amda=
hl=E2=80=99s Law to minimum, because the hardware guys are going to continu=
e throw ever more cores at us for lack of any better idea of what to do wit=
h 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 u=
p=2E
> >
> > I bet the SIMD engines are going to get fancier, too=2E Just look at G=
PUs=2E
> >
> > 	Erik <fair@netbsd=2Eorg>
> >
> >
> >> On Aug 9, 2016, at 11:17, David Holland <dholland-tech@netbsd=2Eorg> =
wrote:
> >>
> >> On Mon, Aug 08, 2016 at 07:36:05PM -0400, Thor Lancelot Simon wrote:
> >>>> Last I remember anyone reporting hard results, the scaling worked t=
o
> >>>> ~16 but not to ~32 and the uvm page queue lock was the chief culpri=
t=2E
> >>>> Dunno what if anything's been done about that=2E=2E=2E
> >>> There's a fragmentary discussion of it from around 2010 in the maili=
ng list
> >>> archives, but something must have been done as that particular limit=
ation
> >>> seems to have gone away=2E  Our build cluster nodes run happily with=
 12
> >>> cores, 24 threads, and I do not see the scaling issues we observed b=
etween
> >>> 16 and 20 cores in my tests years ago=2E
> >> In that case we definitely need someone to collect some hard numbers =
:-)
> >>
> >> --=20
> >> David A=2E Holland
> >> dholland@netbsd=2Eorg
>=20
>