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:
Last but not least,
I'd like to wish belated seasons greetins to all my blog readers,
and also best wishes for 2009 in advance!
- 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
be done. This is what NetBSD's compat32 is all about - binary
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
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
[Tags: amd64, busybox, cauldron, multilib, softdep]
an update on his work on the bouyer-xenamd64 branch:
``a amd64 domU kernel runs stable, and a dom0 kernel boots and can start a domU''.
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]
Status: NetBSD on Xen/amd64
Manuel Bouyer has worked on making NetBSD working on Xen on
the amd64 platform, and he has it has made some substantial
his status mail.
is also available.
[Tags: amd64, dmesg, xen]
NetBSD/amd64 on Shuttle SN27P2 report
Quentin Garnier has installed NetBSD/amd64 on a Shuttle SN27P2.
Hardware support was pretty good, with some funky experiences in the
land of X - see
for the full report, including a link to the
I guess so much for the "NetBSD is only good for old hardware" nonsense...
[Tags: amd64, dmesg]
AMD PowerNow K8 support
PowerNow is AMD's equivalent to Intel's Speed Stepping, which is
``available on all AMD mobile processor-based notebooks that can effectively increase notebook battery life, while delivering performance on demand, for the ultimate mobile computing experience'',
according to AMD's PowerNow page.
NetBSD has support for the i386-based PowerNow K7 for some time
(enable with the POWERNOW_K7 kernel option), and
Juan is working AMD PowerNow K8 support on NetBSD/amd64.
He has some early code available for testing
and feedback, see
as well as
his second mail with more instructions.
Any testers are welcome, please send your feedback
either to the tech-amd64 list,
or directly to Juan.
[Tags: amd64, powernow]
Announcement: AMD64 gains real-time BSD SMP
`` FSMLabs announced Wednesday that it is shipping SMP (symmetric multi-processing) support for AMD's 64-bit Dual-Core Opteron processors running a real-time extension to BSD Unix. The company announced similar Linux support last summer, and says it has already supplied the BSD version of RTCore to network equipment providers (NEPs).
According to FSMLabs, RTCore implements a "host" environment for reliable, real-time operations, while either BSD or Linux function as "guests" OSes. In the case of BSD, RTCoreBSD implements a hard real-time POSIX 1003.13 supervisory kernel with NetBSD 3.0 serving as the guest OS. For Linux, the RTCore kernel works in conjunction with a Linux guest OS, instead of BSD.
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
for free. :-)
[Tags: amd64, Articles, realtime]
Hardware RNG support for EM64T systems
Matthias Scheler has added support for Intel's hardware random number
generator of Intel i9xx chipsets to the NetBSD-amd64 port in NetBSD-current,
to add "random" bits to the rnd(4) pool. He'd appreciate feedback, see
[Tags: amd64, em64t, rng]
First version of COMPAT_LINUX32 imported
Emmanuel Dreyfus has been working on 32bit Linux compatibility for
64bit NetBSD, and he has imported a first version, see
his mail on current-users@.
"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:
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]
Binary packages: Solaris 10/amd64, NetBSD 2.0/sparc64
Gilles Dauphin has made a little number of AMD64 bit package for Solaris10
his mail or
grab them directly.
Havard Eidnes has uploaded
binaries for NetBSD/sparc64 2.0 / pkgsrc-2005Q4.
See his mail or
grab them directly.
[Tags: amd64, packages, solaris, sparc64]
Grab the RSS-feed,
or go back to my regular NetBSD page
Disclaimer: All opinion expressed here is purely my own.
No responsibility is taken for anything.