Apple Releases macOS 10.12 Sierra Open Source Darwin Code
Interesting news come in via slashdot:
Apple Releases macOS 10.12 Sierra Open Source Darwin Code:
``Apple has released the open source Darwin code for macOS 10.12 Sierra. The code, located on Apple's open source website, can be accessed via
direct link now, although it doesn't yet appear on the site's home page. The release builds on a long-standing library of open source code that dates all the way back to OS X 10.0. There, you'll also find the Open Source Reference Library, developer tools, along with iOS and OS X Server resources. The lowest layers of macOS, including the kernel, BSD portions, and drivers are based mainly on open source technologies, collectively called Darwin. As such, Apple provides download links to the latest versions of these technologies for the open source community to learn and to use.''

This may not only be of interest to the
OpenDarwin folks
(or rather their successors in PureDarwin)
but more investigation not only on the code itself,
but also the license it is released under is neccessary
to learn if anything can be gained back for NetBSD.

Why "back"? As you may or may not remember,
mac OS includes some parts of NetBSD (besides lots of
FreeBSD, probably some OpenBSD, much other Open Source
software and sure a big lot of Apple's own code).

As it turns out, Allan Jude and Kris Moore
actually read from some guy's NetBSD blog
starting at 0:22:50, going over the
mumblings onthe NetBSD scheduler there.
Exciting - I think I want to blog about this to get
more NetBSD content on the 'net. ;-)

Now, serious, to avoid getting into a recursive content loop,
I'd like to add one thing that may have caused a bit of confusion
at the end:

The problem mentioned at the end that led to the statement
that the patch wasn't perfect wasn't to blame on the patch,
but on my testing environment.
Using all CPU cores on VMware left none for my
normal operating system, and as such it was not funny to test.
That was the reason why I aborted the build-test went from 4 to 2 CPU cores.
Nothing related to the patch itself.
Sorry to Allan and Kris if that didn't come out clear.
Feel free to add that in BSD now 170! :-)

Reminder: Presentations about either NetBSD itself,
its internals but also how to use NetBSD to do something
cool, neat, useful or just utterly obscure are always welcome.
Let me know, or even better: file your (Euro)BSDCon talk! :)

In-kernel audio mixing ahead
NetBSD's sound device is currently only available for exclusive use.
If one program uses it, another cannot. So if you want to play
some music (mp3, audio stream) that's fine, but if you want
to also have your web browser or mail client make some noise,
this is not possible. Until now.

The solution is to mix
multiple audio sources together, in effect allowing
/dev/sound (etc.) access to be non-exclusive for a
single process but several ones instead.
To make this happen, audio from those sources needs to be
mixed to come out of the same speaker, and since data
writte to /dev/sound gets inside the kernel, that is
a good place to do the mixing.

Challenges in the play are if audio sources are of different
quality (bitrate, stereo/mono, bitrate), so some adjusting
may be needed. All this is met by
the latest patch by Nathanial Sloss,
see
his posting to tech-kern
for more information.

Learning more about the NetBSD scheduler (... than I wanted to know)
I've had another chat with Michael on the scheduler issue,
and we agreed that someone should review his proposed patch.
Some interesting things came out from there:

I learned a bit more about the scheduler from Michael.
With multiple CPUs, each CPU has a queue of processes that
are either "on the CPU" (running) or waiting to be serviced
(run) on that CPU. Those processes count as "migratable"
in runqueue_t.
Every now and then, the system checks all its run queues
to see if a CPU is idle, and can thus "steal" (migrate) processes from
a busy CPU. This is done in
sched_balance().

Such "stealing" (migration) has the positive effect that the
process doesn't have to wait for getting serviced on the CPU
it's currently waiting on. On the other side, migrating the
process has effects on CPU's data and instruction caches,
so switching CPUs shouldn't be taken too easy.

If migration happens, then this should be done from the CPU
with the most processes that are waiting for CPU time.
In this calculation, not only the current number should be
counted in, but a bit of the CPU's history is taken into
account, so processes that just started on a CPU are
not taken away again immediately. This is what is done
with the help of the processes currently migratable
(r_mcount) and also some "historic"
average. This "historic" value is taken from the previous round in
r_avgcount.
More or less weight can be given to this, and it seems
that the current number of migratable processes had too
little weight over all to be considerend.

What happens in effect is that a process is not taken from its
CPU, left waiting there, with another CPU spinning idle.
Which is exactly what I saw
in the first place.

What I also learned from Michael was that there are a number of
sysctl variables that can be used to influence the scheduler.
Those are available under the "kern.sched" sysctl-tree:

The above text shows that much more can be written about
the scheduler and its whereabouts, but this remains to be done
by someone else (volunteers welcome!).

Now, while digging into this, I also learned that I'm not the first
to discover this issue, and there is already another PR on this.
I have opened PR
kern/51615
but there is also
kern/43561. Funny enough, the solution proposed there is about the same,
though with a slightly different implementation. Still, *2 and
<<1 are the same as are /2 and >>1, so no change there.
And renaming variables for fun doesn't count anyways. ;)
Last but not least, it's worth noting that this whole
issue is not Xen-specific.

So, with this in mind, I went to do a bit of testing.
I had already tested running concurrent, long-running processes
that did use up all the CPU they got, and the test was good.

To test a different load on the system,
I've started a "build.sh -j8" on a (VMware Fusion) VM with 4 CPUs on a
Macbook Pro, and it nearly brought the machine to a halt - What I saw was
lots of idle time on all CPUs though. I aborted the exercise to get some
CPU cycles for me back. I blame the VM handling here, not the guest
operating system.

I restarted the exercise with 2 CPUs in the same VM, and there I saw load
distribution on both CPUs (not much wonder with -j8), but there was also
quite some idle times in the 'make clean / install' phases that I'm not
sure is normal. During the actual build phases I wasn't able to see idle
time, though the system spent quite some time in the kernel (system).
Example top(1) output:

Looking at the scheduler issue again (Updated)
I've encountered a
funny scheduler behaviour the other day in a Xen enviroment.
The behaviour was that
CPU load was not distributed evenly on all CPUs, i.e. in my case
on a 2-CPU-system, two CPU-bound processes fought over the same
CPU, leaving the other one idle.

I had another look at this today, and was able to reproduce the
behaviour using VMWare Fusion with two CPU cores
on both NetBSD 7.0_STABLE as well as -current, both with
sources as of today, 2016-11-08.
I've also
made a screenshot available
that shows the issue on both systems.
I have also
filed a problem report
to document the issue.

The one hint that I got so far was from Michael van Elst that
there may be a rounding error in sched_balance().
Looking at the code, there is not much room for a rounding error.
But I am not familiar enough (at all) with the code, so I cannot judge
if crucial bits are dropped here, or how that function fits in the
whole puzzled.

Update:
Pondering on the "rounding error", I've setup both VMs with
4 CPUs, and the behaviour shown there is that load is
distributed to about 3 and a half CPU - three CPUs under
full load, and one not reaching 100%. There's definitely
something fishy in there.
See screenshot.

Splitting up the four CPUs on different processor sets with one process
assigned to each set (using psrset(8)) leads to an even load distribution
here, too. This leads me to thinking that the NetBSD scheduling works
well between different processor sets, but is busted within one set.

NetBSD 7.0/xen scheduling mystery, and how to fix it with processor sets
Today I had a need to do some number crunching using a home-brewn
C program. In order to do some manual load balancing, I was firing
up some Amazon AWS instances (which is Xen) with NetBSD 7.0.
In this case, the system was assigned two CPUs, from dmesg:

I expected something like WCPU and CPU being around 100%, assuming
that each process was bound to its own CPU. The values I actually
saw (and listed above) suggested that both programs were fighting
for the same CPU. Huh?!

This confirmed my suspicion that both processes were bound to one
CPU, and that the other one was idling. Bad! But how to fix?

One option is to kick your operating system out of the window,
but I still like NetBSD, so here's another solution:
NetBSD allows to create "processor sets",
assign CPU(s) to them and then assign processes to
the processor sets. Let's have a look!

Processor sets are manipulated using the
psrset(8) utility. By default all CPUs are in the same (system) processor set:

NetBSD 7.0.2 released
Why 7.0.2? Following
NetBSD's release scheme,
there are major releases (e.g. 7.0) with subsequent updates (e.g. 7.1).
Those "major" release and their updates include both new features
as well as bug fixes - the latter one again with and without security
relevance. New code, new risks - as a result for getting updates,
existing interfaces may change and lead to incompatibiltites.
This may affect either binary compatibility between programs
and their required shared libraries, as well - though rare - incompatible
chances on the source code level.

NetBSD takes quite some effort to keep such incompatibilites
low, yet they happen. The only real solutions is: no updates.
"Never change a running system" is nice for availability,
but it poses security risks. The time when a big server uptime
was considered a sign of good system administration are gone.
Today, a long update means the system (probably) runs outdated
and as such vulnerable code.

So to solve the problem a compromise is needed: little updates,
but crucial security updates do get done. Which is where
NetBSD's "minor" release like NetBSD 7.0.2 come into play.
With its set of changes, a number of external software packages
got security-related updates (e.g. OpenSSL, NTP, BIND, X),
and a smaller number of security related changes were also added,
e.g. a race condition in mail.local(8), crashes in the Networking
File System (NFS) and the native Fast File System (FFS) plus
some platform-specific crashes on MIPS, PowerPC and SPARC64.

Interview with spz@ on BSDnow
There is an
interview of Petra "spz@"
at BSDnow.
She talks about how she got into Unix and NetBSD,
and talks about all the different hats she has
in the NetBSD Project and The NetBSD Foundation, TNF.
The interview starts at Minute 26 -
have a look!

Catching up: audio-mixing, arm, x86 and amd64 platform improvements and security
A few noteworthy things have happened in NetBSD land,
and being lazy I will collect them in one blog posting.
Here we go:

In-kernel audio mixing:
So far, NetBSD's audio device can only be opened once.
If more than one application wants to play sound, the first one wins.
This is suboptimal if you want to (say) play some MP3s
but also get some occasional noise from your webbrowser.

Now, Nathanial Sloss has made a stab at this, providing
several implementation choices. Challenges in the task
are that sounds with different quality (sampling rate,
mono/stereo etc.) need to be brought to one common
quality before mixing and passing on to the actual audio
hardware. Further fun is added by the delay this process
adds.
See the discussion on tech-kern
for all the gory details!

Freescale i.MX7 support:
Ryo Shimizu has committed support for the
Freescale i.MX7 processor
and the Atmark Techno Armadillo-IoT G3 board.
according to
his posting to port-arm (dmesg included),
UART, Ethernet, USB, SDHC, RTC, GPIO, WDOG and MULTIPROCESSOR work.
Interesting thing of the platform is that is has
two Cortex-A7 cores and one Cortex-M4 core, the latter without
MMU. Ideas on how to use the latter are welcome! :)

- I cleaned up the asm code and fixed several comments, which makes the
boot process much easier to understand.
- I fixed the alignment for the text segment, so that it can be covered by
more large pages [1] - thereby reducing TLB contention.
- I fixed a bug in the way the secondary CPUs are launched [2], which
caused them to crash if they tried to access an X-less page.
- I took rodata out of the text+rodata chunk, and put it in the data+bss+
PRELOADED_MODULES+BOOTSTRAP_TABLES chunk [3]. rodata was no longer large
page optimized, and had RWX permissions.
- I retook rodata out of the rodata+data+bss+PRELOADED_MODULES+
BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
the W permision [4].
- I made the kernel map rodata without the X permission, by using the NOX
bit on its pages [5] (now that the secondary CPUs could handle that
properly).
- I took the data+bss chunk out of the data+bss+PRELOADED_MODULES+
BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
X permission [6].
- I made the kernel remap rodata and data+bss with large pages and proper
permissions [7] - which reduces once again TLB contention.

- on non-PAE i386, NOX does not exist. Therefore the mappings all have an
additional X permission. To benefit from X-less mappings, your CPU must
support PAE, and your kernel must be GENERIC_PAE.
- the segments are not large-page-aligned, which means that probably some
parts of the segments are still mapped with normal pages. It is still more
optimized than it used to be, but not as much as amd64 is.