Also seeing 2 x quad-core system slower that 2 x dual core

[Oliver Fromme]

Steven Hartland wrote:
 > sysctl -a |grep dirhash
 > 
 > Check vfs.ufs.dirhash_mem is not close to vfs.ufs.dirhash_maxmem if it is
 > and only most used boxes this seems to be the case increase maxmem.
 > 
 > Seems this could either do with an auto tune option or a larger max by
 > default in today's day and age.

I think it would make sense to tie it to the maxusers value
(which in turn depends on the amount of RAM, by default).

For example, setting dirhash_maxmem to maxusers/32 MB with
a lower limit of 2 MB seems reasonable.  By default, the
maximum of the autotuned maxuers value is 384, so the auto-
tuned value of dirhash_maxmem would be between 2 and 12 MB,
depending on the amount of RAM.  Of course the admin could
still adjust it manually if required.

I.e. something like this:

--- ufs_dirhash.c.orig	2005-10-31 16:41:28.000000000 +0100
+++ ufs_dirhash.c	2007-12-11 13:56:05.000000000 +0100
@@ -1074,6 +1074,9 @@
 void
 ufsdirhash_init()
 {
+	ufs_dirhashmaxmem = maxusers * (1024 * 1024 / 32);
+	if (ufs_dirhashmaxmem < 2 * 1024 * 1024)
+		ufs_dirhashmaxmem = 2 * 1024 * 1024;
 	ufsdirhash_zone = uma_zcreate("DIRHASH", DH_NBLKOFF * sizeof(doff_t),
 	    NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
 	mtx_init(&ufsdirhash_mtx, "dirhash list", NULL, MTX_DEF);

I haven't actually tried that, though, but the patch is
trivial enough so there shouldn't be too many bugs.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

We're sysadmins.  To us, data is a protocol-overhead.