From owner-freebsd-arch Tue Jul 24 22:16:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2377437B409; Tue, 24 Jul 2001 22:16:21 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6P5GG541239; Tue, 24 Jul 2001 22:16:16 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Jul 2001 22:16:16 -0700 (PDT) From: Matt Dillon Message-Id: <200107250516.f6P5GG541239@earth.backplane.com> To: "David O'Brien" Cc: Mike Silbersack , arch@FreeBSD.ORG, Bosko Milekic , "David O'Brien" Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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