Re: Support for large mfs
:Hi, : : Today, we tried to create a 5Gig mfs. It turns out this is :not such a good idea. It turns out that support is basically :limited to an int. Extracts from some of the appropriate files :show some of the problems... More then just a few MFS uses an mmap()'d segment, so you can't create an MFS partition larger then what a process can mmap() anyway. The max is going to be around 2-3 GB. You should be able to create a large virtual VN device. man vnconfig for more information - you have the choice of making it file-backed, swap-backed, or swap-backed with the swap pre-reserved. file-backed VN devices have a sector size of 512 bytes (which is standard). Swap-backed VN devices have a sector size of a page (4K on PC's). vnconfig up a VN device, disklabel it, and newfs away. You can also turn softupdates on in the VN filesystem partitions. I've tested VN all the way to a terrabyte - and just managed to newfs it before I ran out of swap :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Workaround for hanging on exit: patch for review
On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled: | I often notice processes hanging forever on exit's ttywait when TCP | connection dropped. Here is a patch I plan to commit which restrict | waiting for output drain by 3 minutes. Any comments, improvements or | objections? ---end quoted text--- This sounds really absurd and "bike shed"ish. Please make that 5 minutes. I frequently connect to places that have 2~3 minute lag. :) -- [EMAIL PROTECTED] - Is this a stupid host? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PATCH: http://phk.freebsd/dk/misc/vm_vm_zone_h.patch
Removes 43 unneeded #include vm/vm_zone.h includes. Comments, tests and reviews please -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
At 11:05 PM -0700 2000/4/26, Matthew Dillon wrote: You should be able to create a large virtual VN device. man vnconfig for more information - you have the choice of making it file-backed, swap-backed, or swap-backed with the swap pre-reserved. file-backed VN devices have a sector size of 512 bytes (which is standard). Swap-backed VN devices have a sector size of a page (4K on PC's). Hmm. This has got me thinking I use a mfs for storing the Diablo history file on our news peering server. Yes, I know the front part of the file is mmap()'ed and effectively kept completely in memory anyway, but I've seen periods of time when we received over 160,000 articles in a single hour (an average of about 45 per second), and if you compare this to our normal ratio of offered versus accepted articles (something in the range of 32,238,303 vs. 612,429; for a 52.64:1 ratio), this would imply we probably did something like 2,368.8 history lookups per second during that period of time -- and this is just for inbound articles. In my experience, it is a non-trivial exercise to build a drive array system that can keep up with the number of disk accesses necessary to handle this many history lookups per second. I think I've recently done it (and reported my testing results on news.software.nntp, along with summarizing the previous test results from Joe Greco and Terry Kennedy), but it's still non-trivial and the solutions I've seen so far are all still rather expensive. Thus the reason why I currently continue to use an mfs for the history database. However, now I'm wondering if it might not be better to use a file-backed or maybe a swap-backed VN device instead of an mfs. Do you have any thoughts? -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: Removal of unneeded sys/kernel.h
In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote: New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch This patch removes 67 unneeded instances of #include sys/kernel.h Comments, tests and reviews please. Have you checked that there are no references which are #ifdefed out? Yes, the src/tools/tools/kerninclude script first renames the include and if the source file still compiles it declares a "no-read" and leaves the #include intact. The thing that's screwed me up the most doing this sort of thing is something like: #include net/if_tun.h /* For TUNS* ioctls */ #ifdef TUNSIFMODE /* Make sure we're POINTOPOINT */ iff = IFF_POINTOPOINT; if (ID0ioctl(bundle.dev.fd, TUNSIFMODE, iff) 0) log_Printf(LogERROR, "bundle_Create: ioctl(TUNSIFMODE): %s\n", strerror(errno)); #endif hence the comments beside many of the includes in ppp. I think the only way to ensure something really can be removed is to compile with without and ensure that the resulting object is the same modulo embedded compile dates. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: Removal of unneeded sys/kernel.h
In message [EMAIL PROTECTED], Brian Somers writes: Yes, the src/tools/tools/kerninclude script first renames the include and if the source file still compiles it declares a "no-read" and leaves the #include intact. The thing that's screwed me up the most doing this sort of thing is something like: #include net/if_tun.h /* For TUNS* ioctls */ #ifdef TUNSIFMODE /* Make sure we're POINTOPOINT */ iff = IFF_POINTOPOINT; if (ID0ioctl(bundle.dev.fd, TUNSIFMODE, iff) 0) log_Printf(LogERROR, "bundle_Create: ioctl(TUNSIFMODE): %s\n", strerror(errno)); #endif hence the comments beside many of the includes in ppp. I think the only way to ensure something really can be removed is to compile with without and ensure that the resulting object is the same modulo embedded compile dates. If the MD5 over the generated object file changes after substituting an empty file for the include, I consider it "used" by default, so that case should be covered as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS - what's happening with it?
At 1:02 PM +0800 2000/4/27, Stephen Hocking-Senior Programmer PGS SPS Perth wrote: Haven't seen any discussion for quite some time. The Linux people seem to be getting into a lather about it as well. Rehashing the issues like device persistence, et cetera. Yeah, there's a really fascinating summary of a whole lot of things happening for kernel 2.4 at http://kt.linuxcare.com/kernel-traffic/kt2424_64.epl, including the devfs and procfs stuff. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
: I use a mfs for storing the Diablo history file on our news :peering server. Yes, I know the front part of the file is mmap()'ed :and effectively kept completely in memory anyway, but I've seen :periods of time when we received over 160,000 articles in a single :hour (an average of about 45 per second), and if you compare this to :our normal ratio of offered versus accepted articles (something in :the range of 32,238,303 vs. 612,429; for a 52.64:1 ratio), this would :imply we probably did something like 2,368.8 history lookups per :second during that period of time -- and this is just for inbound :articles. : : In my experience, it is a non-trivial exercise to build a drive :array system that can keep up with the number of disk accesses :necessary to handle this many history lookups per second. I think :I've recently done it (and reported my testing results on :news.software.nntp, along with summarizing the previous test results :from Joe Greco and Terry Kennedy), but it's still non-trivial and the :solutions I've seen so far are all still rather expensive. Thus the :reason why I currently continue to use an mfs for the history :database. : : However, now I'm wondering if it might not be better to use a :file-backed or maybe a swap-backed VN device instead of an mfs. Do :you have any thoughts? : :-- : These are my opinions -- not to be taken as official Skynet policy :== :Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV I can't imagine why MFS would perform better... it shouldn't, every block is stored in system memory *TWICE* (once in the VM cache, and once in the mfs process's address space). If you have enough system memory to create a large MFS filesystem and it performs well, then the system should perform even better if you remove the MFS filesystem and just use a normal filesystem. A swap-backed VN device operates just like a normal disk device except that you get automatic striping if your swap happens to be striped. It takes advantage of the fact that the system's VM page cache does a good job of caching the disk blocks so it doesn't have to. This is how a normal filesystem works as well. If you have enough memory, the system should be able to cache a normal filesytem's data blocks as easily as it caches the VN devices and easier (because they aren't double-cached) then the MFS device. I would consider trying a normal filesystem with an async or a softupdates mount. Or a normal filesystem with softupdates enabled. It may also help to turn off write-behind (sysctl -w vfs.write_behind=0), though if you are running the latest 4.x stable the write heuristic is now in and should do a good job on its own. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld breakage in getconf
On Thu, 27 Apr 2000 12:52:21 +0100, "Peter Edwards (local)" [EMAIL PROTECTED] said: Compiling 5.0-CURRENT on 4.0-STABLE generates problems in getconf: I got caught out by gperf version skew. gperf is now a build-tool (as it should always have been) so this problem should be fixed in your next update. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
At 9:34 AM -0700 2000/4/27, Matthew Dillon wrote: I can't imagine why MFS would perform better... it shouldn't, every block is stored in system memory *TWICE* (once in the VM cache, and once in the mfs process's address space). If you have enough system memory to create a large MFS filesystem and it performs well, then the system should perform even better if you remove the MFS filesystem and just use a normal filesystem. When I tried using a regular file on the filesystem, my system time went way up, my iowait went way up, and my performance dropped through the floor. However, this was on 3.2-RELEASE and was several months ago -- I hope that 4.0-STABLE would be a bit better about that. ;-) I would consider trying a normal filesystem with an async or a softupdates mount. Or a normal filesystem with softupdates enabled. It may also help to turn off write-behind (sysctl -w vfs.write_behind=0), though if you are running the latest 4.x stable the write heuristic is now in and should do a good job on its own. I believe I had tried this with softupdates at the time, but it's been long enough since I tried this that I can't be sure. I do recall seeing my performance go down quickly enough and seeing the disk I/O go through the roof fast enough that I decided I would never, ever, ever try that again. Of course, now I am revisiting that decision. ;-) I'm seriously contemplating getting a Dell PowerEdge 2450 with five internal 10kRPM/18GB disks, 2GB of RAM, two of the fastest processors they've got, perhaps a pair of Intel EtherExpress Pro 100+ NICs, and giving this another go with FreeBSD 4.0-STABLE. Do you have any thoughts on this subject? Is 3.2-RELEASE old and non-optimized enough that it really could stand replacing? Given some of the problems we've been seeing lately (which I'm pretty sure are a result of running out of virtual memory and the machine spontaneously rebooting), I think I might be able to convince my management to spring for a third 2450, but with a slightly different configuration than what I'll be using for the news reader servers. It would help me formulate useful arguments for this proposal if I had input from more knowledgeable people than I. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
: : Do you have any thoughts on this subject? Is 3.2-RELEASE old and :non-optimized enough that it really could stand replacing? 3.2 is certainly old. The question is whether or not the performance issue that caught you under 3.2 is fixed under 4.0. Not knowing what was causing the hangups under 3.2 I can only guess that there's a 50-50 change it's been fixed in 4.0. I'm trying to think of what Diablo could be doing that would cause the system to stall on the history file, and I can't think of anything. It ought to work pretty well certainly as good or better then MFS, anyway. I suspect that if the issue still exists it's going to be something stupid simple that doing something trivial like turning off write-behind will fix. -Matt : Given some of the problems we've been seeing lately (which I'm :pretty sure are a result of running out of virtual memory and the :machine spontaneously rebooting), I think I might be able to convince :my management to spring for a third 2450, but with a slightly :different configuration than what I'll be using for the news reader :servers. : : It would help me formulate useful arguments for this proposal if :I had input from more knowledgeable people than I. : :-- : These are my opinions -- not to be taken as official Skynet policy :== :Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
I'm seriously contemplating getting a Dell PowerEdge 2450 with five internal 10kRPM/18GB disks, 2GB of RAM, two of the fastest processors they've got, perhaps a pair of Intel EtherExpress Pro 100+ NICs, and giving this another go with FreeBSD 4.0-STABLE. I would consider 4.0, several (three or four) strings of LVD disks and either a Mylex eXtremeRAID 1100 (64MB or more) or an AMI MegaRAID Enterprise 1500. (The 1600 should probably work too, but I haven't seen one yet so I can't be sure.) And definitely softupdates. Note that you can't put more than 8 disks into an array with the Mylex controller (easily), so you'd still want to use ccd or vinum over the top. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage in getconf
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote: I got caught out by gperf version skew. gperf is now a build-tool (as it should always have been) so this problem should be fixed in your next update. Was this not ``make buildworld'' tested, or is there a change to gnu/usr.bin/gperf/Makefile you forgot to commit? - -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage in getconf
On Thu, Apr 27, 2000 at 12:46:43PM -0400, Garrett Wollman wrote: I got caught out by gperf version skew. gperf is now a build-tool (as it should always have been) so this problem should be fixed in your next update. cc -pipe -O -DSHELL -I. -I/FBSD/src/bin/sh -Wall -Wformat-static mksyntax.o -o mksyntax cd /FBSD/src/gnu/usr.bin/gperf; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /FBSD/src. *** Error code 1 Stop in /FBSD/src. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage in getconf
On Thu, 27 Apr 2000 12:23:20 -0700, "David O'Brien" [EMAIL PROTECTED] said: Was this not ``make buildworld'' tested, or is there a change to gnu/usr.bin/gperf/Makefile you forgot to commit? I am obviously *way* out of date with the state of the build system I was trying to quickly get things back working again for upgrade builds, and ended up breaking everything sigh -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS - what's happening with it?
-On [2427 07:05], Stephen Hocking-Senior Programmer PGS SPS Perth ([EMAIL PROTECTED]) wrote: Haven't seen any discussion for quite some time. The Linux people seem to be getting into a lather about it as well. Rehashing the issues like device persistence, et cetera. If I recall correctly, Boris Popov is working on that, next to his SMB code. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Answering the questions that no one asks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD build status
=== SUMMARY === World ***didn't compile*** 3 Warnings Kernel LINT compiled 147 Warnings Kernel GENERIC compiled 58 Warnings Kernel GENERIC98 ***didn't compile*** 63 Warnings === Compile errors for kernel GENERIC98 === cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pc98/pc98/wd_cd.c In file included from ../../pc98/pc98/wd_cd.c:44: ../../pc98/pc98/wormio.h:9: warning: `/*' within comment ../../pc98/pc98/wormio.h:117: unbalanced `#endif' *** Error code 1 (continuing) `all' not remade because of errors. === Compile errors from make world === cd /otte/src/games/phantasia; make build-tools cc -O -pipe -c -o cross-phantglobs.o /otte/src/games/phantasia/phantglobs.c cc -O -pipe -c /otte/src/games/phantasia/setup.c cc -static -O -pipe-o setup cross-phantglobs.o setup.o -lm cd /otte/src/gnu/usr.bin/gperf; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /otte/src. *** Error code 1 Stop in /otte/src. *** Error code 1 Stop in /otte/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
At 10:16 AM -0700 2000/4/27, Mike Smith wrote: I would consider 4.0, several (three or four) strings of LVD disks and either a Mylex eXtremeRAID 1100 (64MB or more) or an AMI MegaRAID Enterprise 1500. (The 1600 should probably work too, but I haven't seen one yet so I can't be sure.) And definitely softupdates. That would be for a spool server, but a news peering server shouldn't need that many disks. I was planning on doing four 10kRPM/18GB disks with a small RAID 0+1 partition for /usr/news/history (and a separate one for the /usr/news/spool), but four separate filesystems mounted under /usr/news/spool/news, and doing it all with vinum. I figure if I lose a single disk, 1/4 of the spool will be toast but /usr/news/history and /usr/news/spool will still be okay (albeit reduced in performance), and vinum should be quite fast enough for what will be asked of it. Note that you can't put more than 8 disks into an array with the Mylex controller (easily), so you'd still want to use ccd or vinum over the top. I'm doing that now on our news spool server, for similar reasons -- it can't make simultaneous use of more than five disks in a LUN, and can't do its own striping across LUNs. In fact, I'd be extremely interested to know if you can build a Mylex or AMI RAID configuration that is optimized for random read performance that can perform on the same sort of levels as the 1.8TB news spool server that Joe Greco built (and reported on in news.software.nntp), the solid-state disk that Terry Kennedy has on his news peering server (and reported on in news.software.nntp), or the news spool server I've built (and reported on in news.software.nntp ;-). -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release breakage
Hello, make release fails with the following diagnosis: === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat *** Error code 71 -- Best regards, Ilya mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
...snip... Its nice to see someone actually using kobj so soon. There is a possible performance problem though - kobj method calls are roughly 20% slower than direct function calls. Having said that, this isn't that slow - I timed a method call to a two argument function at ~40ns on a 300MHz PII. I could improve this for some applications (including this one) by providing a mechanism for an application to cache the function pointer returned by the method lookup. Yes, this sounds interesting. I can see that there are provisions for a cache in the code, and I can see from the sysctls that hits and misses are happening, but I can't see where the function pointers are entered into the cache. Is this enabled by default? It also might be possible to have default implementations that do "less than nothing", a special value could be entered in the cache that indicates don't call through the function pointer at all. I don't know how an inline cache lookup would compare to an empty function call, but it might be a win when the locks are supposed to do nothing. Anyway, I've made a patch that uses Boris's suggestion of providing functions with empty bodies. I worry about optimizing for the static UP kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it should just be a function call in all cases. http://io.yi.org/lock.diff I will send-pr it if no one has any comments. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Wed, Apr 26, 2000 at 08:53:52AM -0700, Frank Mayhar wrote: "Frankly, my dear, I don't give a damn." Richard, for the record, I'd like to point out that the person who said this is not a developer and therefore the backlashing you're getting is not solely from developers. Other people are sick of your crap, too. :) -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
On Tue, Apr 25, 2000 at 09:48:18PM +1000, Sheldon Hearn wrote: If that's the _only_ point, then Garrett Wollman's idea should work perfectly. Stick the files under CVS, just agree that they should never be revised, but rather that new versions should be imported in a different directory and the old versions punted to the Attic. AFAIK, ctm (not sure about CVSup) doesn't support a rename function - when a file is deleted into the Attic, ctm deletes the old file and then creates a new file in the Attic (transferring the content). So this approach probably wouldn't solve Julian's immediate problem. Apart from that, this approach seems significantly better than (effectively) committing diffs to binary files. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL asm optimizations
On Fri, 21 Apr 2000, Kris Kennaway wrote: OpenSSL includes asm code for several platforms to speed up various operations. Currently we don't build any of this - the attached patch turns on asm code for Pentiums and above (it relies on an uncommitted patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. On Sat, Apr 22, 2000 at 02:35:51PM +1000, Matthew N. Dodd wrote: Can these be turned on at runtime? Not the way the libraries are currently structured. There are a number of libraries where we would get significant speedups by supporting target-dependent code. I can think of three possible ways of supporting this: 1) Use machine-depend shared libraries to replace functions in the standard shared libraries. This approach is used on Solaris - the rtld automatically loads a machine-specific library (if it exists) before libc.so. The disadvantages are: - no support for static executables or in-line functions - slower startup due to the extra libraries (particularly if Kris's idea of an ordered list of machine architectures) - increased VM usage due to multiple function versions in the process address space - I'm not sure how difficult it would be to integrate into FreeBSD's lazy binding scheme 2) Use indirect function calls, with run-time initialisation to setup the pointers. This approach is used in the kernel for bzero/bcopy. The disadvantages are: - no support for in-line functions - need to invoke a library initialisation routine (not too difficult with ELF) - increased function call overheads (indirect rather than direct calls). - increased VM usage due to multiple function versions in the process address space 3) Have separate library versions for each target. - Significant increase in disk space occupied by libraries All the approaches increase the build time since multiple copies of functions need to be built. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Workaround for hanging on exit: patch for review
On Thu, Apr 27, 2000 at 01:06:16AM -0500, Michael C . Wu wrote: On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled: | I often notice processes hanging forever on exit's ttywait when TCP | connection dropped. Here is a patch I plan to commit which restrict | waiting for output drain by 3 minutes. Any comments, improvements or | objections? ---end quoted text--- This sounds really absurd and "bike shed"ish. Please make that 5 minutes. I frequently connect to places that have 2~3 minute lag. :) And make it sysctl-controllable, perhaps? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage
Ilya Naumov wrote: Hello, make release fails with the following diagnosis: === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /R/stage/trees/bin/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat *** Error code 71 I just finished one a couple of hours ago with a cvsup and world this morning of course I do it with NODOC=yes. ed Making fixit floppy. disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn0c:2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g) super-block backups (for fsck -b #) at: 32 2606 blocks Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounte d on /dev/vnn0c 1363 1322 -68 105% 353 2992% /mnt Filesystem is 1440 K, -68 left 4000 bytes/inode, 29 left touch release.9 0 blocks Setting up CDROM distribution area 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks Setting up FTP distribution area 0 blocks 0 blocks Release done + echo make release Finished make release Finished To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel panic at boot with 2 printers
Sorry not to have details at hand but anyways: Current cvsupped today. I have 2 parallel ports in use. I have had no problems with kernels dated 2 weeks or older, but since a few days ago, the system crashes at boot while probing the parallel ports. "Page fault while in supervisor mode", (I seem to remember vaguely) If I disable either lpt0 or lpt1 in -c config, the system boots and operates without problems. I know this is a terrible bug-report, but perhaps it still could trigger the memory of whoever made changes to the printer system I can provide better info tomorrow if needed, but it's so late I can't find a pencil to write the exact messages. 'night Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
On Fri, 28 Apr 2000 09:37:40 +1000, Peter Jeremy [EMAIL PROTECTED] said: How do you suggest such files get distributed? cvsup and/or rsync. This does leave CTM-users the odd men out As Matt pointed out, CVS provides us with a good mechanism for ensuring that I can identify what version of the firmware I am using - and be reasonably certain it matches the code that Matt (or whoever) validated. So would simply naming the files by version. This works because most if not all of our drivers use firmware from another vendor with its own version-numbering scheme. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
Hi Matthew, On Thu, 27 Apr 2000, Matthew Dillon wrote: I can't imagine why MFS would perform better... it shouldn't, every block is stored in system memory *TWICE* (once in the VM cache, and once in the mfs process's address space). If you have enough system I've been running a MFS /tmp dir since around 2.2.4, are you now saying that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed vnode fs? Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for large mfs
:Hi Matthew, : :On Thu, 27 Apr 2000, Matthew Dillon wrote: : : I can't imagine why MFS would perform better... it shouldn't, every : block is stored in system memory *TWICE* (once in the VM cache, and : once in the mfs process's address space). If you have enough system : :I've been running a MFS /tmp dir since around 2.2.4, are you now saying :that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed :vnode fs? : :Carl. With a softupdates /tmp, the only thing MFS will save you are the write-behind disk writes on large files. The cost to using MFS is that every disk block in an MFS filesystem is in main memory twice. If you do anything significant in your /tmp this will strain the VM system. In general, an MFS /tmp does not give you enough of an advantage to be worth it. I would go with a normal UFS /tmp with softupdates enabled. A Swap-backed VN /tmp will work as well, but keep in mind that the sector size is 4K and you should use the appropriate options to vnconfig to pre-reserve the swap space so performance does not degrade from fragmentation. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test for 8G-OVER-Booting with /boot/loader
Hi At Tue, 28 Mar 2000 06:46:27 -0500 (EST), John Baldwin [EMAIL PROTECTED] wrote: Looks good to me, but I need to test it to make sure. I will also look at seeing if I can squeeze the int 13 extension installation check into boot1 and boot0 so that they will use packet mode automatically as well. Oh, I remember. This just checks if the controller supports LBA. You also need to check if the drive supports LBA. The problem is with older drives. Hmm, I'll look around to see if you can ask the BIOS for drive capabilities. I have convinced that there are no widespread services to query whether drive supports LBA. So I changed my patch to use Packet I/F only when we need to access over 8GB. Please review and test following patch. Thanks. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan biosdisk.c.diff
Re: asm_pci.h,v Holy cow!
I don't see the purpose of having a firmware image permanently resident (especially given their sizes). Getting the boot loader to directly load the firmware into the device seems a much nicer solution. If this is impractical, treating the firmware as a kld and unloading it after downloading the firmware would seem the next best option. There's an open PR on this one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: Removal of unneeded sys/kernel.h
On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote: New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch This patch removes 67 unneeded instances of #include sys/kernel.h Comments, tests and reviews please. Just write a script to check all #include's against their prototypes and have it autogen diffs. I'm sure perl mavens will say that'll only take about 100 lines of perl. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: Removal of unneeded sys/kernel.h
Will Andrews wrote: On Wed, Apr 26, 2000 at 11:50:11AM +0200, Poul-Henning Kamp wrote: Comments, tests and reviews please. Just write a script to check all #include's against their prototypes and have it autogen diffs. I agree. I like the automated method better. What happens if someone accidentally commits an additional unnecessary #include after the patch has been applied? - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: Removal of unneeded sys/kernel.h
On Fri, Apr 28, 2000 at 07:45:36AM +0200, Poul-Henning Kamp wrote: I agree too, but nobody has written *that* code yet. Instead of trying to find these yourself, why not invest this time in writing said script? :) (I'm not volunteering for this.. ;-) -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
