On 24.10.2012 16:26, Vadim Goncharov wrote:
Hi,
We have 'maxusers' tunable which affects many other tunables, e.g. number of
network mbuf/clusters which is often too low on current machines.
The mbuf/cluster limit can be rethought as well. Since it all comes
out of UMA and is not pre-allocated we could simply set it to
"physpages / 2" or "physpages / 4 * 3". Relating it to maxusers isn't
meaningful anymore.
In the same area the kern.maxfiles, kern.maxfilesperproc and
kern.ipc.maxsockets need rethinking as well. For modern systems and
busy servers it should be at least in the 100k area, if not more.
It should have some magic value per GB physical memory as well.
You have to make sure that this is true though:
kern.maxfiles > kern.ipc.maxsockets > kern.maxfilesperproc
There is code in sys/kern/subr_param.c:
if (maxusers == 0) {
maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE);
if (maxusers < 32)
maxusers = 32;
if (maxusers > 384)
maxusers = 384;
}
It was capped to 384 for i386 KVM size limits in r89769, so that amd64, not
constrained to 1Gb KVA, suffers from this. I suspect that 384 may be wrong even
for i386 today, but let's be conservative and limit maxusers to 384 per 1 Gb of
KVM, like this:
#define _MAX_MAXUSERS (((VM_MAX_KERNEL_ADDRESS - \
KERNBASE) / (8 * 1024 * 1024)) * 3)
if (maxusers == 0) {
maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE);
if (maxusers < 32)
maxusers = 32;
if (maxusers > _MAX_MAXUSERS)
maxusers = _MAX_MAXUSERS;
}
#undef _MAX_MAXUSERS
This is very round-about. Why don't you simply write 384 per GB in
there directly?
Thinking of it these "magic" whatever-per-GB value definitions
should be next to each other in param.h or some other suitable
place.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
