Date: Tue, 24 Jul 2001 22:16:16 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "David O'Brien" <obrien@FreeBSD.ORG> Cc: Mike Silbersack <silby@silby.com>, arch@FreeBSD.ORG, Bosko Milekic <bmilekic@technokratis.com>, "David O'Brien" <nobody@nuix.com> Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c Message-ID: <200107250516.f6P5GG541239@earth.backplane.com> References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My only comment here is to be mindful of the trouble we ran into with
the buffer cache (for example)... running out of KVM space due to KVM
not scaling with real memory. I think we not only want to try to
scale w/ real memory, we also need to cap it based on KVM.
For the suggestion below (2048 + MAXUSERS * 16), we have to be careful
in regards to losing our ability to operate on machines with small
amounts of memory. It may be a good idea to implement the real memory
*AND* the KVM-based cap now in order to prevent both the low-memory case
and the too-much-memory case from blowing up KVM.
(I also agree re: maxfiles/sockets, with the same stipulation - based on
the maximum malloc area size).
I think KVM management has gotten to the point where we might as well
setup page tables for the entire 1GB, which will cost us 1MB of ram
for page tables. If we do that it will remove or greatly reduce one of
the many problems we have to deal with. Then if someone decides to shift
the kernel start address down we can simply assume that that means they
want even *more* KVM space. The real and KVM scaling code would take
care of the rest.
-Matt
:> In 4.x, the setting is currently at:
:> (512 + MAXUSERS * 16)
:>
:> current was
:> (1024 + MAXUSERS * 16)
:>
:> before your scaling change (to * 64).
:>
:> How about we instead change the constant amount, to perhaps:
:> (2048 + MAXUSERS * 16)
:
:I am open to this change, but would like see others comment also on this
:proposal.
:
:> (I'd like to do the scaling based on RAM size,
:> but I don't have time at the moment.)
:
:Agreed. I started on a set of diffs, but have not had time to finish
:them and test them.
:
:> Note that if we're increasing this, we should probably increase
:> maxfiles/sockets - that's probably more important now.
:
:Any one else with an opinion on this?
:
:--
:-- David (obrien@FreeBSD.org)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107250516.f6P5GG541239>