Date: Wed, 05 Dec 2001 22:15:30 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Xu <davidx@viasoft.com.cn> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Lamont Granquist <lamont@scriptkiddie.org>, Mike Barcroft <mike@FreeBSD.ORG>, Jim Durham <jimd@nepinc.com>, Jordan Hubbard <jkh@winston.freebsd.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Can TCP changes be put in RELENG_4? Message-ID: <3C0F0D02.8AEA9E48@mindspring.com> References: <20011205085750.I28101-100000@coredump.scriptkiddie.org> <200112052142.fB5LgVM53167@apollo.backplane.com> <3C0EF953.54CF24DB@mindspring.com> <3C0F0803.7010506@viasoft.com.cn>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > > It will be still a defacto, because Linux distributions will always > install tuned version of Linux kernel as default Tuned for what? > while FreeBSD not, the default GENERIC FreeBSD kernel's performace > sucks, For what application? > and ordinary user will find FreeBSD is slower, could we let user to > select which kernel to install at installing time? It's a possibility that I've considered, given that sysinstall had a hard time supporting installing FreeBSD from a single CDROM image to support both developers and the end product with a single "golden" system image. The problem with doing this is that it sort of grates against the idea of a "GENERIC" entirely. It also provides a false sense of security, should FreeBSD go to such a mechanism, and then have a canned "firewall" (for example). The main problem which needs addressing is that the allocation mechanisms are Schitzophrenic in whether they can be used at interrupt time, or not. If they can be used at interrupt time, then they require mapping preallocation, at a minimum, and then, generally, underlying page preallocation, as well. The problem with mapping preallocation, even if you eat the "allocation failed because of no backing pages" bullet (i.e. for mbuf allocations) is that it cuts chunks out of the KVA map which can then not be used for other applications. There is also a dichotomy in the mapping for swappable vs. non memory; swappable does best with 4K page mapping (for obvious reasons), while non-swappable does best with 4M mappings (also for obvious reasons). The only method I could think of to deal with this is to grow the non-swappable up and the swappable down (you would generally want to try to keep non-swappable memory low to permit access by hardware, and making swappable memory high has the advantage of being able to handle 16G of RAM on some current hardware, if you support bank selection of the top 1G (or 2G, if you are agressive). Really, it boils down to the allocation systems needing rewrite, and (painful as this is to say) a move away from type stable memory, to permit reuse, rather than static purposing of large blocks: static purposing is the primary reason a general turning can not be near optimal for a lot of applications. If you want to discuss this further, the -arch list is probably the best place to hold the discussion, since this is not a decision that can reasonably be made in -hackers. -- 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?3C0F0D02.8AEA9E48>