From owner-freebsd-hackers Fri Nov 30 15:39:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 4187537B417 for ; Fri, 30 Nov 2001 15:39:45 -0800 (PST) Received: from dialup-209.247.143.43.dial1.sanjose1.level3.net ([209.247.143.43] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 169xFu-00048j-00; Fri, 30 Nov 2001 15:39:43 -0800 Message-ID: <3C0818EA.B34721FB@mindspring.com> Date: Fri, 30 Nov 2001 15:40:26 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Luigi Rizzo , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP Performance Graphs References: <20011130141100.B90969@ussenterprise.ufp.org> <20011130112215.H30981@iguana.aciri.org> <20011130135042.G46769@elvis.mu.org> <20011130135402.H46769@elvis.mu.org> <20011130125839.A88302@ussenterprise.ufp.org> <20011130102928.E30981@iguana.aciri.org> <20011130141100.B90969@ussenterprise.ufp.org> <20011130112215.H30981@iguana.aciri.org> <20011130135042.G46769@elvis.mu.org> <20011130171418.B96592@ussenterprise.ufp.org> <20011130163405.O46769@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > Hmm, well the GENERIC default is some mathematical operation on > maxusers. We really ought to make this scale as a default relative > to the amount of ram in the system, rather than some low hardcoded > value. NetBSD has some stuff for this in their buffercache sizing > algorithm in netbsd-stable. It might be worth checking out, the > formula is quite smart such that it has a decent size when system > ram is low, then for each meg above X it increases it by some > percentage. I find it to be too low, but whatever. :) This is an arbitrarily hard problem to solve correctly. The problem boils down to the inability to do allocations at interrupt, unless there is a prereserved mapping backing store already in place. This works for systems where the memory size << KVA space, but when you stick 4G in a machine, the code in the kernel is way, way off (the machdep.c calculations for swap page mappings and others go off the scale, unfortunately). I think that what needs to happen is a reconsideration of the memory allocation system, almost entirely. THe seperation needs to be into swap path and non-swap path, rather than into allocable at interrupt time, and not. I hate to suggest it, but... perhaps a move away from type stable memory would not be a bad thing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message