[SANE-UG] Epic yak shaving exercise

[Sevan / Venture37]

Hello,
From one of the FreeBSD devs on the cluster administration team.
https://blog.crashed.org/one-of-those-days/

Check out the series of events in the summary section :)

Sevan / Venture37
_______________________________________________
SANE-UG mailing list
SAN...@saneusergroup.org.uk
http://sane-ug.brighton.org/mailman/listinfo/sane-ug
Google Groups (RO) http://groups.google.com/group/sane-ug
Flickr http://www.flickr.com/groups/sane/
Twitter @saneug

[Dave Phelan]

<like>

On Thu, Aug 18, 2016 at 2:49 PM, Sevan / Venture37 <vent...@gmail.com>
wrote:

--
Dave Phelan CCIE#3590 skype:davephelan GSM: 07990561784
dave....@gmail.com @daveph http://www.davephelan.org

"The best wifi is just that: free wifi throughout, no codes, no charges."
- William Gibson, http://tinyurl.com/2u4873

[Glyn Grinstead]

On Thu, 18 Aug 2016 at 14:49:36 +0100, Sevan / Venture37 wrote:
> Hello,
> >From one of the FreeBSD devs on the cluster administration team.
> https://blog.crashed.org/one-of-those-days/

Today I've made my own small contribution to ensuring the FreeBSD yak is
completely smooth and stubble free.

I noticed a couple of days ago that a custom kernel build of 10-STABLE was
failing and today tracked down which line (out of 54) in my local kernel
config was causing it (nooptions SMP) and which revision (r303776)
introduced the problem, which involved building the odd kernel or ten (not
to mention a couple of buildworlds) on a box very unsuited to any hard work.
I then realised I have some very minor make.conf optimisations - nothing
that would cause a problem, but it's not fair to raise a PR with more
variables than is strictly necessary, so another build to be certain.

All to achieve... well, not much really. While it should be possible
to build a kernel without SMP, there can't be many people who might
benefit from it today.

And that doesn't include me.

The reason I have 50-odd lines of no[makeoptions|options|device] in this
kernel conf is due to noticing I had 800MB allocated to wired memory (that
is, non-swapable memory, usually kernel related) on a box with only 1GB of
memory. It turned out that by madly chopping irrelevant bits out of the
kernel I could gain a massive 10 or 20MB back. What *really* made a
difference was adding kern.maxusers="64" to /boot/loader.conf (and possibly
also kern.maxfiles="25000" which I seem to have added at about the same
time). It appears that sometime in the recentish past the metric used to
auto-set these values started making much more generous use of hardware than
was appropriate for my archaic kit. I now have 127MB wired and a massive 8MB
active memory in use and, well, the lack of SMP code really isn't doing
anything exciting.

Or in other words, I just spent a day tracing a problem that I no longer
have.

But, out of a noble interest in my fellow users (who may even reach double
figures) who are also building non-SMP kernels for their own perverse
reasons, I've just raised a PR for this.

Glyn.

(Of course, it's entirely possible that it's some other long forgotten
abomination of my configuration that's causing this, but that's what
happens when you're dealing with yaks).

[Sevan / Venture37]

On 20 August 2016 at 20:16, Glyn Grinstead <gl...@grinstead.org> wrote:
> Today I've made my own small contribution to ensuring the FreeBSD yak is
> completely smooth and stubble free.

:D
lovely!
How come you're explicitly building non-SMP kernels?


Sevan / Venture37

[Glyn Grinstead]

On Sun, 21 Aug 2016 at 17:47:23 +0100, Sevan / Venture37 wrote:
> How come you're explicitly building non-SMP kernels?

I suspect that very question is currently going through John Baldwin's head
as well, as it is in his capable hands that my PR is resting.

The truth is I have no reason today for building non-SMP kernels. While this
is on a single core box, that doesn't mean it was ever a particularly
sensible thing to do. The original reason (and removing support for SCSI
cards[1], RAID controllers, ISA ethernet, etc.) was attempting to discover
where all my wired memory had gone but that turned out to be something
different; much as the removal of atkbdc, atkbd and psm didn't help with the
system that failed to start a usb keyboard two times out of three (but still
lives on in the kernel config on that box).

As my upgrade-from-source script looks to see if I'm running a custom kernel
and builds both the custom and the generic kernels automatically (generic
then installed to one side as /boot/kernel.GENERIC) I immediately knew the
problem was linked to the custom kernel, and that the sensible fix would be
to stop gratuitously meddling with Things People Were Not Meant To. But that
wouldn't be any fun.

Besides, I figure that if I carry this on far enough I'll have the world's
first micro-kernel FreeBSD system. It won't actually be able to *do*
anything apart from print a version string[2], but it'll be efficient.

I do now have a vision of jhb sitting there tossing a coin muttering "Heads
I fix the bug, tails I deprecate nooptions SMP..."

Glyn.

[1] If trying this at home, remember that many non-SCSI like things use
parts of the SCSI code to interface with the system. Try not to
remove that.

[2] To memory, as it won't support any output devices.