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.
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
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.
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]
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
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.''
iMil's email to tech-userlevel
and the thread following it for more information.
- In a similar line as crunchgen and BeastieBox is
``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