Date: Fri, 30 Nov 2001 15:40:26 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <bright@mu.org> Cc: Luigi Rizzo <rizzo@aciri.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: TCP Performance Graphs Message-ID: <3C0818EA.B34721FB@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C0818EA.B34721FB>