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.

[Tags: amd64, scheduler, xen]

• iMil (of pkg_select fame) has started work on BeastieBox, which is a BusyBox-like system for NetBSD. The goal is to provide a single binary that can be used for many things, usually (hard)linked to various names, to be as space efficient as possible.

  NetBSD has provided a very good build mechanism for such binaries that run as a single statically linked binary for several programs via crunchgen(8) - a notable example of such a program can be found in NetBSD's /rescue. Note that all the files in there are hardlinks to a single file on disk, which contains all that's needed to run, no extra shared libs etc. are needed!

  What's new/different in BeastieBox from crunchgen is that there three modes available: ``a semi-static mode, where all commands will be statically linked to the main executable, still dynamically linked over libc and libm, a full static mode, where the produced binary is statically linked over all needed libraries, and a dynamic mode, where commands are available as shared objects. As an example, when using dynamic mode, "beastiebox" binary will load libifconfig.so when invoking the ifconfig command.''

  See iMil's email to tech-userlevel and the thread following it for more information.

• In a similar line as crunchgen and BeastieBox is Brian Seklecki's Cauldron Project: ``The Cauldron Project (formally bsd-appliance) is derived from work done at Collaborative Fusion, Inc. with the goal of developing a scalable and manageable enterprise-class BSD-based appliance platform. [...]

  The current framework is ideal for bona-fide network appliances: Routers, Firewalls (Policy Routers), Set Top Boxes, Console Servers, RAS Terminal Concentrators, Wireless Access Points (APs), Load Balancers / Application Switches, IDS Sensors, Network Cameras, Environmental Sensors , as well as other heavyweight appliances NAS Storage, Proxy Servers, E-mail SPAM Filters, DNS Slaves.

  ISVs, Small-Medium size businesses, OEMs, and Individuals alike will also find the system useful for systems such as Set Top Boxes, Point of Sale (POS) Terminals,

  In theory the framework could also be used in embedded applications such as micro-firmware for Printers, Scientific Instruments, Phones and other mobile communications and multimedia devices. '' The project's looking for active developers, so if this is something that may be of use to you, join in!

• The NetBSD operating system supports a wide range of hardware platforms, among them 32bit and 64bit platforms. In that context, "32bit" and "64bit" usually describe the width of data words used in various system APIs. A "32bit" usually uses 32bit (4 Bytes) wide data types for integers, pointers and C "long" datatypes, which is why it is also referred to more precisely as "ILP32 platform". In contrast, on 64bit platforms, C "long" and pointer datatypes are usually 64bit (8 bytes) - note that integers usually remain at 32bit. Now with C APIs using all those data types back and forth, it's clear that exchange of data between a 32bit application and a 64bit operating system is not so easy, as quite some conversion work needs to be done. This is what NetBSD's compat32 is all about - binary compatiblity.

  When compiling a program on a 64bit system, it will of course use the 64bit interfaces. Building a 32bit binary on a 64bit system is usually not so easy, and effectively ends up in setting up much of a crosscompiler environment. All this is enabled in NetBSD 5.0 by default (or will be, once 5.0 is released ;-) under the "multilib" keyword.

  In order to make it easy to build 32bit binaries on a 64bit platform, Jared McNeill has posted a howto for building 32-bit packages on 64-bit platforms with pkgsrc. Enjoy! :-)

  (BTW: building sparc binaries on a sparc64 system should work in a similar fashion).

• Last, an end-of-life notice for soft-dependencies from Andrew Doran: ``Soft dependencies, also known as soft updates or softdep, is a method of maintaining file system integrity across an unscheduled system shutdown. It improves file system performance by allowing metadata writes to the file system to take place asynchronously. Soft dependencies was introduced with NetBSD 1.5.

  The upcoming 5.0 release of NetBSD will include an alternative technology contributed by Wasabi Systems Inc.: Write Ahead Physical Block Logging, or logging. Logging will provide a feature set and performance profile superior to soft dependencies. One compelling advantage is that file systems using it need not be checked with the fsck utility after an unscheduled system shutdown.

  In NetBSD 5.0 both soft dependencies and an experimental, preview implementation of logging will be available. From NetBSD 6.0 onwards, soft dependencies will no longer be shipped as part of the system and logging will be the preferred method of maintaining file system integrity with FFS file systems.''

Manuel also outlined his future plans: ``Once bouyer-xenamd64 is merged, I'll start a new branch to work on switching xeni386 to the new x86 pmap and xenamd64 bootstrap codes, and merge back code from xen/i386 to i386/i386. I'll also look at x86pae support in Xen, as using the x86 pmap should make this much easier.''

Esp. the bit about PAE is very desirable, as it currently stops NetBSD from working as domU with a Linux dom0 that has PAE enabled (which is the default nowadays). Every Linux user that wants to try NetBSD in a Xen domU currently has to make sure he has a non-PAE kernel first, which is suboptimal.

[Tags: amd64, xen]

I guess so much for the "NetBSD is only good for old hardware" nonsense...

[Tags: amd64, dmesg]

RTCore first supported BSD kernels in May, 2002. RTCore's AMD64 support, implemented for Linux in July, can be used with AMD Opteron, Athlon 64, and Turion 64 chips.''

NetBSD 3.0/amd64 with no realtime support can be found here for free. :-)

[Tags: amd64, Articles, realtime]

"What's the fuss, NetBSD already runs Linux binaries?!" you may ask. The point is: Running 32bit binaries on a 64bit system needs a bit more work. A "32bit system" is also known as ILP32, i.e. it has types 'int', 'long' and pointers 32bit, while "64bit systems" are also known as "LP64" systems because they have types 'long' and pointers with 64bit. Now guess what happens when you run a binary that was build on a system with long=32bit on a system with long=64bit: strange things! For things to work properly, arguments from and to system calls need to be converted, in addition to all those semantic changes when emulating a different Unix system (Linux).

[Tags: amd64, linux]

Havard Eidnes has uploaded binaries for NetBSD/sparc64 2.0 / pkgsrc-2005Q4. See his mail or grab them directly.

[Tags: amd64, packages, solaris, sparc64]