hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
 
[20161109] 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.

[Tags: , , ]


[20081229] Catching up: BusyBox-alikes, softdep EOL, 32bit pkgsrc on 64bit platforms
I've been slacking^Wterribly busy again, so there have been a few things to mention in NetBSD-land in the mean time:
  • 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