Date: Thu, 30 Jun 2005 14:15:31 +0200 From: Max Laier <max@love2party.net> To: freebsd-hackers@freebsd.org Cc: ant <andrit@ukr.net> Subject: Re: hot path optimizations in uma_zalloc() & uma_zfree() Message-ID: <200506301415.38106.max@love2party.net> In-Reply-To: <000d01c57cf7$b9b6f9f0$29931bd9@ertpc> References: <000d01c57cf7$b9b6f9f0$29931bd9@ertpc>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1192332.03hU8Kq6Lb
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 30 June 2005 00:08, ant wrote:
> I just tryed to make buckets management in perCPU cache like in
> Solaris (see paper of Jeff Bonwick - Magazines and Vmem)
> and got perfomance gain around 10% in my test program.
> Then i made another minor code optimization and got another 10%.
> The program just creates and destroys sockets in loop.
>
> I suppose the reason of first gain lies in increasing of cpu cache hits.
> In current fbsd code allocations and freeings deal with
> separate buckets. Buckets are changed when one of them
> became full or empty first. In Solaris this work is pure LIFO:
> i.e. alloc() and free() work with one bucket - the current bucket
> (it is called magazine there), that's why cache hit rate is bigger.
>
> Another optimization is very trivial, for example:
> - bucket->ub_cnt--;
> - item =3D bucket->ub_bucket[bucket->ub_cnt];
> + item =3D bucket->ub_bucket[--bucket->ub_cnt];
> (see the patch)
Might be me, but this doesn't change the generated object code at all (modu=
lo=20
the changed __line__ in debugging).
> the patch is for uma_core.c from RELENG_5, but i checked
> uma_core.c in CURRENT - it's the same regarding to thiese
> improvements. I don't have any commit rights, so the patch
> is just for reviewing. Here it is:
>
> --- sys/vm/uma_core.c.orig Wed Jun 29 21:46:52 2005
> +++ sys/vm/uma_core.c Wed Jun 29 23:09:32 2005
> @@ -1830,8 +1830,7 @@
>
> if (bucket) {
> if (bucket->ub_cnt > 0) {
> - bucket->ub_cnt--;
> - item =3D bucket->ub_bucket[bucket->ub_cnt];
> + item =3D bucket->ub_bucket[--bucket->ub_cnt];
> #ifdef INVARIANTS
> bucket->ub_bucket[bucket->ub_cnt] =3D NULL;
> #endif
Okay, but no effect according to my reading of the object code.
> @@ -2263,8 +2262,7 @@
> if (bucket->ub_cnt < bucket->ub_entries) {
> KASSERT(bucket->ub_bucket[bucket->ub_cnt] =3D=3D NULL,
> ("uma_zfree: Freeing to non free bucket index."));
> - bucket->ub_bucket[bucket->ub_cnt] =3D item;
> - bucket->ub_cnt++;
> + bucket->ub_bucket[bucket->ub_cnt++] =3D item;
This changes semantics, as far as I understand. Might be a consequence of =
the=20
other work you are doing, but doesn't seem right from a first glance.
=2D-=20
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--nextPart1192332.03hU8Kq6Lb
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQBCw+JqXyyEoT62BG0RAr95AJ9vjKZpC3esckfOCbHaqLwJvG5VmgCeJWsY
bp4IPxkZoF6bHvZ0fYJUoHc=
=80+J
-----END PGP SIGNATURE-----
--nextPart1192332.03hU8Kq6Lb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506301415.38106.max>