From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 16 Jan 2014 17:42:41 -0500
To: 9fans@9fans.net
Message-ID: <3b9f16aa4996024459d81b932bd2f448@brasstown.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] nix allocb stats
Topicbox-Message-UUID: b3c27aa6-ead8-11e9-9d60-3106f5b1d025

i thought this was interesting.  this is from a small, 1 package
system.  it gives a feel for the basic performance of the quick
list allocb under low load, which isn't too bad:

this is just after boot,

ivey# awk '$1=="allocb" {printf "%s\t%d\n", $0, int($4/$3)}' < /dev/swap
#quicklist sz	count	cycles	cycles/alloc
allocb 128:	8595	2043800	237
allocb 1520:	29	236908	8169
allocb 9000:	119	105680	888
allocb 16384:	7174	1923500	268
allocb 65536:	122	66280	543

and this is after pushing a bit of tcp:

ivey# awk '$1=="allocb" {printf "%s\t%d\n", $0, int($4/$3)}' < /dev/swap
allocb 128:	38084	7199704	189
allocb 1520:	56139	9075432	161
allocb 9000:	10127	2437248	240
allocb 16384:	7178	1927092	268
allocb 65536:	152	79528	523

it looks like the call to physalloc is pretty pricey, but keeping the quicklist
makes that irrelevant in the steady state.

as to counts bigger than 64k, this is not allowed.  allocb will just panic.

- erik