Just uncovered a stonking design flaw in the freelist elimination layer.

The idea is to have one cache line for every logical core.

What I was actually doing was having one atomic_isolation per logial core.

On CAS platforms, this is nominally one cache line (except of course Intel are now bringing over two cache lines at once, so even there it’s wrong) but on ARM where the max ERG is 2048, instead of having one cacheline I had a huge 2kb.

So what I actually need is one cache line, with atomic_isolation separation.

forum and mailing list issues

So, I’ve just tried logging into both the forum and the mailing list, as admin, and neither work.

I have no clue why, and they were working last time I used them, and everything else seems to be fine, and there is as far as I can tell no logging.

I’ll fix it soon, but probably I will ditch both of the them (Dadamail was likely to go anyway). That means going back to EsoTalk for the forum, and maybe a non-GUI install of mailman for the mailing list.

Ugh. Jesus. Forums and mailing lists and open source software. Ugh.

offsets rather than absolute pointers

So, bugger me, been off work for a week and a half and only now finally had time to think a bit about something which has been on my mind for agggges – using offsets rather than absolute pointers.

The idea is to make it possible to share data structure instances across processes without having to have the same virtual address base, and between the kernel and user-mode.

So, having thought it over, there’s an obvious limitation; we can only use entities (structures, for state and elements) which are in the same single contiguous memory block.

Consider; say you allocate one block of memory, for a freelist state and a hundred freelist elements.

You share this between two processes. They each now have a different virtual address (first is at say 10,000, the second and 10 million), but the whole block is contiguous from that address.

The freelist internally uses offsets; so both processes can push and pop from the freelist and everything is fine.

Now let’s say the freelist elements each contain a btree element.

We then share the btree state between the processes.

Now we pop a freelist element and we want to insert it into the btree.

The problem is the btree is also using offsets; but the offset from the btree state to the freelist element *is different in each process*, because the freelists have different virtual memory addresses. (Also, ptrdiff_t is only allowed in the spec to show the difference between pointers in the same block of memory – in part most likely because of situations like this!)

So we simply *cannot* use anything other than those things which are in the same conitiguous block of memory.

So if we had one block of memory which contained the btree state, the freelist state and the freelist elements, then we’d be fine – so it *is* still useful.

But one thing we do lose is the ability when a freelist is empty to do a malloc and throw some more elements on there – because they will be in a different, non-conitiguous block.

One thing to also consider is the void pointer of user data. What this is set to is entirely up to the user, but the user faces the same problems as the data structure, so they will also need to use values which make sense across processes and/or kernel/user-mode.

So I’m working now on an experimental freelist with offsets.

Pretty cool if it works – you can take an instance of a data stucture, and use it concurrently over multiple kernel threads at the same time as you use it with multiple threads *in multiple different processes*.

So much to kernel/user-mode isolation… =-)


Well, I’ve set up Dadamail.

It’s pretty bad, in many ways. It tracks users, too, what they’re doing with the email – opening it, etc. I don’t want that. The emails themselves also are ugly as hell – I mean, *seriously*.

The big thing going for it is that nothing else works.

Well, I’ll think it over. I’ll get the forum back up now, and then tomorrow get all the builds passing on all platforms.

Then I can get back to actual dev work.

Avoid CPAN. Maybe avoid Dadamail (except the alternatives are worse).

Jesus Christ on a stick.

CPAN (the Perl module installer) does not support unintallation.

I’m staggered.

So, I’ve been setting up DadaMail, this mailing list thing.

The author has had a go at doing documentation and by open source standards it is exemplary. By actual “is it accurate and are there any surprises?” standards, it’s pretty rough.

So I completed all the install configuration and hit go and it’s happy but it also *then* finally says “install the DadaMail Perl module for greatly enhanced capabilities!”

First time that’s been mentioned.

So I do it.

It does not install cleanly. For one thing, it actually wanted openssh-dev, for another, about half-way through, you get a bizzare question, “where are the apache sources?”


So I hit “q” (like, don’t search) and then it keeps going and there’s a good chunk of errors here and there and then it finishes and I’m thinking, this is a mess, let’s uninstall it.


(drum roll…)

CPAN does not support uninstall.


I mean, seriously.

And the lesson is – even the most basic, most fundamental, most you would never imagine in your wildest dreams someone making a system without it – even that cannot be assumed to exist in open source.

Open source software all lacks professionalism; none of it has polish, like a product. Open source also I think has the greatest range of quality, because commercial software which isn’t any good dies.

So you get things like this. Staggering surprises from out of the blue.

Now I’ve got some god-knows-what god-awful mess spamming up my Perl config, and no way to get rid of it.

-1 for Dadamail, -1 for CPAN.

Mailman Bounced

Mailman has no documentation.

That’s basically the truth. Oh – there’s a bit – couple of paragraphs about setting up the MTA (very confusing paragraphs, Linux mail servers are a living hell to comprehend/configure) and that’s it.

The same docs exist in a couple of places on the net, in different formats, and in various places point to each other. This is not helpful.

An honourable mention must also go to the fact that having visited the Mailman download page, I had no idea how to download Mailman.

So, after a bit you realise Mailman has no built-in web-interface.

This is a separate project.

You then look for it.

There’s a GitLab repo – the wiki is empty and there are no docs to be seen, except a readme.

In the readme the sole sign of docs is a link to one of the web-sites holding a copy of the it’s-not-documentation-really docs. Having realised what the WWW interface is called, I then look at its section.

This doesn’t take long, it’s very short.

In fact, it at the start contains a link to “Mailman Bundler”, as an easy way to install everything.

This sounds just the ticket – at least, in principle – so I head over.

“All of this documentation is obsolete! Mailman Bundler is no longer recommended or supported. Do not use it to try to install GNU Mailman 3, you will be frustrated. Please go see the Mailman Suite documentation instead. It includes links for setting up all the components.”

I head back.

Turns out the WWW interface runs on Django.

Okay, this is seriously not what I’m looking for, and I’d actually say seriously not *right*.

I’m reading typically small Django apps take about 70mb of RAM.

I have 1 GB on my VM.

I’m looking for a mailing list, right? it takes an email now and then, and users subscribe and unsubscribe once in a blue moon, using a CGI, which takes no resources at all and just writes a row or two to the database.

Resource usage should be approximtely *zero*.

This does not equate with what seems to be a range of always-running processes and 70mb of RAM.

I’m going to look a bit more at Mailman. Maybe it’s configured and is actually working, and so maybe I can just set up a static page with email addresses on, to subscribe/unsubscribe.

Well, I looked.

It doesn’t work out of the box.

You’re supposed to do this;

mailman info

To generate the initial config file.

What I get it this;

ImportError: No module named core.i18n

There’s no sign of documentation or information on pre-requisites.

I’m bailing out now. If the experience so far is like this, it’s going to be like this after I get it working too, even if I do.

Once bitten, twice shy.

If a project looks bad, it probably is bad.

There might be – *might* be – a core of gold in there, but it’s fabulously easier just to go and find a project which actually *is* working out of the box and *has* documentation.

site status update


Friday before last I asked for the VM image on the server to be replaced by a fresh Debian 8 Jessie image. It was on Wheezy and the distro-update hadn’t worked properly.

This was done, and the new root password emailed to me (I know – I’ve told them about this already, a year ago; but they’re still apart from that the best Swiss provider wholly within Switzerland).

Problem was that the email address they sent that to…

…was on the server which was wiped by the VM image replacement.

So I got the password on Monday.

I then had my final three days in my (now previous) job, which were busy – and I continue to be busy with that, in fact.

My most pressing concern was to get the mediawiki back up. This took a day and a half, because the instructions in the Apache 2.4 docs for using FastCGI with php5-fpm simply do not work and it took up a lot of time finding that out. I found a different way to configure in the end.

The nice thing now is that since I have in the end moved back to Apache, and slapped the seemingly-crazy mpm_event config into shape (I do *not* understand all this “we can spin up more servers” stuff – if your machine lacks the resources for high load, it won’t be able to do this anyway), and now I can install Bugzilla and Mailman, neither of which could be done with nginx (no CGI support – in fact Apache has the obvious solution to handle the problem, have a tiny extra server which you issue CGI requests to and it spawns itself).

So I’m now installing Bugzill and Mailman.

Intel cache line lengths

Just found this…

> We would have to extend our notion of “CPU architecture” for that to
> make sense. For example, Pentium Pro / II CPUs had cache line size of
> 32 bytes, Intel Netburst CPUs (all Pentium-4 and Xeons of the time)
> have / had 128 bytes, while Pentium-III, Pentium-M and later Core CPUs
> have 64 bytes. They are all I686_CPU in our view.


I assumed 32 bit Intel was 32 byte cache line, 64 bit Intel was 64 byte cache line.

See? getting that Minnowboard has already uncovered something critical.