hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
 
[20170325] NetBSD and Google's Summer of Code: Students can apply now
This year's Summer of Code has reached the phase where interested students can hand in project applications. Deadline for submissions is April 3rd 2017, so hurry up to get in line!

We have a list of project ideas available.

Please feel free to discuss project ideas beforehand on our mailing lists. When discussing project ideas, make sure you had a look at our guidelines, and answer as many questions as possible.

[Tags: ]



[20170228] NetBSD will be in Google's Summer of Code 2017
NetBSD will be in the 2017 Google Summer of Code as one of the mentoring organizations. Right now, NetBSD projects for this summer are under discussion internally, but interested students are again welcome to start looking and participating, discussing project ideas of existing or new projects on our mailing lists, The next still on the timeline will be March 20th 2017 when students will be able to apply for projects officially. Stay tuned!

[Tags: ]


[20170109] Documenting NetBSD's scheduler tweaks
NetBSD's scheduler was recently changed to better distribute load of long-running processes on multiple CPUs. So far, the associated sysctl tweaks were not documented, and this was changed now, documenting the kern.sched sysctls.

For reference, here is the text that was added to the sysctl(7) manpage:

     kern.sched (dynamic)
             Influence the scheduling of LWPs, their priorisation and how they
             are distributed on and moved between CPUs.

                   Third level name              Type       Changeable
                   kern.sched.cacheht_time       integer    yes
                   kern.sched.balance_period     integer    yes
                   kern.sched.average_weight     integer    yes
                   kern.sched.min_catch          integer    yes
                   kern.sched.timesoftints       integer    yes
                   kern.sched.kpreempt_pri       integer    yes
                   kern.sched.upreempt_pri       integer    yes
                   kern.sched.maxts              integer    yes
                   kern.sched.mints              integer    yes
                   kern.sched.name               string     no
                   kern.sched.rtts               integer    no
                   kern.sched.pri_min            integer    no
                   kern.sched.pri_max            integer    no

             The variables are as follows:

             kern.sched.cacheht_time (dynamic)
                     Cache hotness time in which a LWP is kept on one particu-
                     lar CPU and not moved to another CPU. This reduces the
                     overhead of flushing and reloading caches.  Defaults to
                     3ms.  Needs to be given in ``hz'' units, see mstohz(9).

             kern.sched.balance_period (dynamic)
                     Interval at which the CPU queues are checked for re-bal-
                     ancing.  Defaults to 300ms.  Needs to be given in ``hz''
                     units, see mstohz(9).

             kern.sched.average_weight (dynamic)
                     Can be used to influence how likely LWPs are to be
                     migrated from one CPU's queue of LWPs that are ready to
                     run to a different, idle CPU.  The value gives the per-
                     centage for weighting the average count of migratable
                     threads from the past against the current number of
                     migratable threads.  A small value gives more weight to
                     the past, a larger values more weight on the current sit-
                     uation.  Defaults to 50 and must be between 0 and 100.

             kern.sched.min_catch (dynamic)
                     Minimum count of migratable (runable) threads for catch-
                     ing (stealing) from another CPU.  Defaults to 1 but can
                     be increased to decrease chance of thread migration
                     between CPUs.

             kern.sched.timesoftints (dynamic)
                     Enable tracking of CPU time for soft interrupts as part
                     of a LWP's real execution time.  Set to a non-zero value
                     to enable, and see ps(1) for printing CPU times.

             kern.sched.kpreempt_pri (dynamic)
                     Minimum priority to trigger kernel preemption.

             kern.sched.upreempt_pri (dynamic)
                     Minimum priority to trigger user preemption.

             kern.sched.maxts (dynamic)
                     Scheduler specific maximal time quantum (in millisec-
                     onds).  Must be set to a value larger than ``mints'' and
                     between 10 and ``hz'' as given by the kern.clockrate
                     sysctl.  Provided by the M2 scheduler.

             kern.sched.mints (dynamic)
                     Scheduler specific minimal time quantum (in millisec-
                     onds).  Must be set to a value smaller than ``maxts'' and
                     between 1 and ``hz'' as given by the ``kern.clockrate''
                     sysctl.  Provided by the M2 scheduler.

             kern.sched.name (dynamic)
                     Scheduler name.  Provided both by the M2 and the 4BSD
                     scheduler.

             kern.sched.rtts (dynamic)
                     Fixed scheduler specific round-robin time quantum in mil-
                     liseconds.  Provided both by the M2 and the 4BSD sched-
                     uler.

             kern.sched.pri_min (dynamic)
                     Minimal POSIX real-time priority.  See sched(3).

             kern.sched.pri_max (dynamic)
                     Maximal POSIX real-time priority.  See sched(3).


[Tags: , ]


[20170109] NetBSD 7.1_RC1 available
Well, subject says it all. To quote from Soren Jacobsen's email: ``The first release candidate of NetBSD 7.1 is now available for download at:

http://cdn.NetBSD.org/pub/NetBSD/NetBSD-7.1_RC1/

Those of you who prefer to build from source can continue to follow the netbsd-7 branch or use the netbsd-7-1-RC1 tag.

There have been quite a lot of changes since 7.0. See src/doc/CHANGES-7.1 for the full list.

Please help us out by testing 7.1_RC1. We love any and all feedback. Report problems through the usual channels (submit a PR or write to the appropriate list). More general feedback is welcome at releng%NetBSD.org@localhost.''

[Tags: ]



[20170104] Hotplugging RAM - uvm_hotplug(9), the Xen balloon(4) driver and portmasters' FAQ
Adding and removing hardware components in operation is common in today's commoditized computing environments. This was not always the case - in the past century, one had to power down a machine in order to change network cards, harddisks or RAM. A major step towards changing a system's configuration at runtime for customers came with USB, but that's not where it ends - other systems like PCI support hotplugging as well.

Another area where changing of the system's configuration is the amount of Ramdom Access Memory (RAM) of a system. Usually fixed, this is determined at system start time, and then managed by the operating system's memory managent system. But esp. with today's virtualized hardware systems, even the amount of RAM assigned to a system can easily be changed. For example a VM can be assigned more RAM when needed, without even rebooting the system, leading to increased system performance without introducing swapping/paging overhead. Of course this required support from the operating system and its memory management subsystem.

For NetBSD, the UVM virtual memory system was now changed to support this via the uvm_hotplug(9) API, and a first user for this is the Xen balloon(4) driver. Quoting from the balloon(4) manpage, ``The balloon driver supports the memory ballooning operations offered in Xen environments. It allows shrinking or extending a domain's available memory by passing pages between different domains.''

The uvm_hotplug(9) manpage gives us more information on the UVM hotplug functionality: ``When the kernel is compiled with 'options UVM_HOTPLUG', memory segments are handled in a dynamic data structure (rbtree(3)) com- pared to a static array when not. This enables kernel code to add or remove information about memory segments at any point after boot - thus "hotplug".''

To answer more questions for portmasters who want to change their ports, Cherry G. Mathew has now posted a uvm_hotplug(9) port masters' FAQ. It covers questions on the background, affected files, and needed changes.

For more information on UVM, see Charles' Chuck' Cranor's PhD disertation on Design and Implementation of UVM (PDF) as well as his Usenix talk on the UVM Virtual Memory System (PS). There is also plenty of information available on Xen ballooning - check it out and share your experiences on NetBSD's port-xen mailing list!

[Tags: , , , , ]



[20161222] Bringing the scheduler saga to the finishing line
After my last blog postings on the NetBSD scheduler, some time went by. What has happened that the code to handle process migration was rewritten to give more knobs for tuning, and some testing was done. The initial problem state in PR kern/51615 is solved by the code. To reach a wider audience and get more testing, the code was committed to NetBSD-current today.

Now, two things remain to be seen:

  1. More testing. This best involved situations that compare the system's behaviour without and with the patch. Situations to test include
    • pure computation jobs that involve multiple parallel processes
    • a mix of CPU-crunching and input/output, again on a number of concurrent processes
    • full build.sh examples
    If you have time and an interesting set of numbers, please feel free to let us know on tech-kern@..

  2. Documentation. There is already a number of undocumented sysctls under "kern.sched", which was now extended by one more, "average_weight". While it's obvious to add the knob from the formula, testing it under various real-life conditions and see how things change is left to be determined by a PhD thesis or two - be sure to drop us your patches for src/share/man/man7/sysctl.7 if you can come up with a comprehensible description of all the scheduler sysctls!
So just now when you thought there is no more research to be done in scheduling algorithms, here is your chance to fame and glory! :-)

[Tags: , ]


[20161124] 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).

[Tags: , , ]



[20161124] BSD now 169: Scheduling your NetBSD, plus a comment
BSD Now 169 is out, entitled "Scheduling your NetBSD". Yai, exciting contents in this video BSD centric video podcast!

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 on the 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! :-)

[Tags: , ]



[20161123] EuroBSDCon 2016 Talks and NetBSD
This year's EuroBSDCon took place in Belgrade, and the slides are now available. Have a look at the full lot - or pick the ones that are relevant to NetBSD: 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! :)

[Tags: , , ]


[20161123] 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.

Also, note his request for review and testing! :-)

[Tags: , , ]



Previous 10 entries
Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 23207940
Copyright (c) Hubert Feyrer