Re: genuine cpu I386_CPU kernel support
Julian Elischer wrote: I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) defined(SMP) #error can't have smp on a 386 #endif Paging Terry Lambert...Terry Lambert, to the hackers lounge please. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ACPI-fast default timecounter, but HPET 83% faster
John Baldwin wrote: On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: I'm seeing similar results. [r...@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter ' Timecounter i8254 frequency 1193182 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter HPET frequency 14318180 Hz quality 900 [r...@orangebox /usr/home/gcooper]# ./cgt 1369355 [r...@orangebox /usr/home/gcooper]# sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: HPET - ACPI-fast [r...@orangebox /usr/home/gcooper]# ./cgt 772289 Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =])? I suspect that the quality of the HPET driver is lower simply because no one had measured it previously and HPET is newer and less proven. From memory, HPET was massively slower on some of the AMD test hardware I was using. There was a thread about it on one of the mailing lists, but I can't find it right now. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 6.3/7.1 and Linux disk performance test
Omer Faruk Sen wrote: as you can see there is a big difference in just simple dd test. Is there additional steps that I can follow to increase performance? Use a benchmark that matches your actual workload, and then see how things look. I would be surprised if your target workload was dd :-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lzo2 shows insane speed gap
Christian Weisgerber wrote: Bruce Cran br...@cran.org.uk wrote: I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without malloc debugging (malloc.conf - aj) 'make test' takes 25s; after removing malloc.conf thus turning on debugging, it takes over 10 minutes. Wow! That. Is. It. Toggling malloc debugging option J makes the slow machines fast and vice versa. Athlon 64 X2 5200+ 2.6 GHz, FreeBSD 8.0-CURRENT amd64 ~60 min 19 seconds. I guess that falls under the obvious configuration differences to check, but since it usually doesn't cause a significant slowdown I completely forgot about it. Embarrassing. But still. Two orders of magnitude? That is a pathological case. Probably it means that lzo2 is doing pathological numbers of mallocs. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS make install with exec=no in /tmp
Pegasus Mc Cleaft wrote: Hello hackers, I was wondering if there is a work around for this... In 8.0-current I have installed the new version of ZFS and upgraded the filing systems to 13. I had a thought that I would make a zfs for /tmp and set the exec to no (thinking that nothing should ever be executed in the tmp). All seemed to work ok, however, I ran into a problem when I was installing a new world. The script immediately bombed out with a permission denied message. I remembered seeing that type of message before when I was testing the no- exec bit in /tmp before, so I reset it to 'yes' and all is well and installed fine.. Is there any way to specify what directory is used for building and executing the install scripts? The standard UNIX way is to set the TMPDIR env variable. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Giant lock, bce and uhc using the same irq
On Mon, Nov 17, 2008 at 05:14:21PM +0200, Murat Balaban wrote: Hello hackers, In one of my production servers (64-bit Intel Xeon machine) running 6.3-RELEASE-p4 (amd64) FreeBSD 6.3-RELEASE-p4 #0: Fri Sep 12 17:07:19 EEST 2008 I see this top -S output excerpt: 32 root 1 -68 -187 0K16K *Giant 0 48.3H 3.08% irq17: bce1 uhci1 What I get from above is that bce and uhc drivers both use irq17. I assume bce is SMPng'ed, and uhc is not. Does uhc being Giant locked, affect bce performance, because they use the same interrupt handler thread? bce will not need to acquire Giant at all so they will not fight for the lock. However both of them will have to wake up to check each interrupt so there is some time spent there. Also if you have some other workload on the system that is still heavily dependent onGiant (e.g. MSDOSFS, etc) then that will interfere with uhci while interrupts are coming in. Kris P.S. In 8.0 there is a new USB stack that is Giant-free. -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kvm on amd64 - 6G?
Barry Boes wrote: With the advent of ZFS, Solaris users are devoting 30G or more to their ARC caches today. If FreeBSD 8 is going to up the KVM size, is there a reason to not increase the limit to something that will not be reached in the lifetime of 8? 100GB? It's easily configurable on HEAD. From an email alc sent me: This: Index: amd64/include/pmap.h === --- amd64/include/pmap.h(revision 180373) +++ amd64/include/pmap.h(working copy) @@ -111,7 +111,7 @@ /* Initial number of kernel page tables. */ #ifndef NKPT -#defineNKPT32 +#defineNKPT1023 #endif #define NKPML4E1 /* number of kernel PML4 slots */ Index: amd64/include/vmparam.h === --- amd64/include/vmparam.h (revision 180373) +++ amd64/include/vmparam.h (working copy) @@ -163,7 +163,7 @@ */ #defineVM_MAX_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-1, NPDEPG-1, NPTEPG-1) -#defineVM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-7, 0, 0) +#defineVM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, 0, 0, 0) #defineDMAP_MIN_ADDRESSKVADDR(DMPML4I, 0, 0, 0) #defineDMAP_MAX_ADDRESSKVADDR(DMPML4I+1, 0, 0, 0) will now get you this: vm.kvm_free: 547729960960 vm.kvm_size: 549755809792 on HEAD. :-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kvm on amd64 - 6G?
Daniel O'Connor wrote: On Wed, 27 Aug 2008, Kris Kennaway wrote: will now get you this: vm.kvm_free: 547729960960 vm.kvm_size: 549755809792 on HEAD. :-) Holy fat cache Batman! Any chance it could be made a tunable? I don't know what the impact might be of changing these constants to runtime variable accesses, if they are in a critical path somewhere. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kvm on amd64 - 6G?
Barry Boes wrote: I could apply such a patch to my servers, but there are two disadvantages : o who wants to apply kernel patches to mission critical servers? Isn't that a linux thing (joke!) A trivial tweak would let you set both parameters in your kernel configuration as an option. o what about apps like the linuxulator that might not stand for this? Why do you think they will care? On the tunable option : with today's kmem_size and kmem_size_max tunables, would there also be a need to tune the portion of address space available to kmem? Yes, it is still suballocated out of the kernel map. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netstat: kvm_read: Bad address
vasanth raonaik wrote: Hello Hackers, I am facing with this Issue. Though netstat -a does show some output but the error is consistently seen. Does any one has some pointers to the cause and fix for the same. It is usually caused when your libkvm and/or netstat binary was compiled against different versions of the sources than your kernel. Rebuild world to fix it. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the future of sun4v
Peter Jeremy wrote: [Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy [EMAIL PROTECTED] wrote: I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. I don't have the knowledge or available time to maintain the sun4v port by myself but would be happy to be part of a team doing so. One impediment I have is that I don't have a T-1 or T-2 system that I can dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but since FreeBSD doesn't support either the virtual disk or virtual network, actually getting FreeBSD running there presents somewhat of a challenge. There are two t1000 systems in the freebsd.org cluster that are available for people to work on. Rink Springer has also expressed interest in this. Perhaps Kip can explain some more about what things he looked at, but the most serious bugs might be in pmap or perhaps trap handling. Operationally, things like buildworld -jN die quickly with random signals, kernel traps, etc. Kris P.S. It looks like marius has made progress on US III but sun4u is still an architectural dead end. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
Nikolay Kalev wrote: I would also like to help as well. As KMacy knows before i asked a lot of questions for T2 types of servers but unfortunately i have no more access to those kind of hardware as well. I;m willing to participate if a team will be formated. Just so everyone is on the same page, what is needed to keep sun4v viable are people with experience with (or intention to learn about) low level architectural and implementation details of the FreeBSD kernel and the sun4v hardware platform, who know their way around things like pmap.c and other MD places where the kernel interfaces with the bare metal, and who are willing to make a long term (multi-year) commitment to supporting the platform. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/98388: [ata] FreeBSD 6.1 - WDC WD1200JS SATA II disks are seen as older SATA
sam wrote: Andrey V. Elsukov wrote: sam wrote: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 12 13:54:27 MSD 2008root@:/usr/obj/usr/src/sys/GENERIC i386 | please, any solution ? Probably speed is limited via jumpers on your hard drive. http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1409p_created=#jumper tried it without results So the jumpers were set wrong to begin with, but fixing them didnt help? Check your BIOS SATA support or look for an upgrade. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
Murty, Ravi wrote: Jeremy, thanks. I look forward to switching to ULE in 7.0 and realize that it is a completely new scheduler (I spent some time yesterday looking at it) -- which is my porting effort is much harder than a simple cut and paste. I just wanted to find out if there was something simple I could look at before I spent weeks porting my changes to the scheduler (also I can justify the move to 7.x). I can't figure out why my 8 app threads run so slow -- I am booting the kernel is single user mode with not much else running and my threads do a lot of work and don't really sleep. Once again, ULE in 6.x is too broken to use, which is why major changes were required to get it to a suitable state in 7.0. It's a shame that you didn't read about this before putting in so much work. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Kris I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. SCHED_ULE is much better, so I've switched over. But it's not the default yet, and most people are still going to be using SCHED_4BSD. It used to be acceptable but now it isn't. Does anyone know why it's regressed so badly? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Gábor Kövesdán wrote: Well, it seems you have missed the first nits of the discussion. GNU grep has some regression test, which doesn't pass completely itself either. :) I've mentioned here that I used those tests to find out what incompatible options are there. Unfortunately, I have to say that BSD grep won't pass all of those, because GNU allows some non-standard regexes, which are rejected by our libc-regex library, like for example (a|) is not standard because it has an empty subexpression. First, I tried to pre-edit such expression in the code. It was ugly enough but I thought: Ok, this code is pretty ugly, but compatibility is important, maybe we can later revise and/or change our regexp library and get rid of these snippets. Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. The version that I sent you for the portbuild test, doesn't have those workarounds. The regression test helped though to fix other compatibility issues, like return values. All of these trivial things are supposed to be compatible now, the only exceptions are the non-standard regexes. That's why I'm so curious about the results. If they are inacceptable, we can try to build BSD grep with the GNU regexp lib (it's in the tree, as Pedro F. Giffuni pointed it out). It doesn't work by just linking with that library, so it will need more work and investigation then, not speaking about that GNU regex should go one day... OK, yes I did miss the start of the thread, but I was trying to suggest that grep doesn't seem to be functional enough yet and this is a way to work on identifying what needs to be fixed. Could you please send me some logs of ports which build with GNU grep but not with BSD grep? That would help me to identify the problems and find out if those problems come from non-standard regexes or what's happening here? No, because every port build fails because egrep -v is failing to work properly in the management scripts :) I sent you mail about this already. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
Murty, Ravi wrote: Hello everyone, Finally found what my last problem was. We were running top in a loop and running some workloads that called sched_bind() to bind threads to specific CPUs. The problem was that (and I am using ULE) sched_bind calls a function to notify another CPU of a thread and then mi_switches out of it. Since mi_switch sets the oncpu field of the thread to NOCPU and given the thread is still running, calcru would come in and assert the fact that If I am running I better no be on NOCPU.. It appears that in other parts of the kernel (e.g. forward_signal) this is acceptable (i.e. it is okay to be running and oncpu is NOCPU). Thanks Ravi Don't use ULE in 6.x, it's broken and will not be fixed. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Maxim Sobolev wrote: Dag-Erling Smørgrav wrote: Andrey Chernov [EMAIL PROTECTED] writes: BSD sort as an idea will be a good project indeed, but BSD sort implementation we currently have at hand is totally misleading and should be rewritten from the scratch, I realize it when long time ago I try to localize it for single byte locales. I think part of the problem is that there aren't enough people who truly understand localization. I think I understand most of it, but I'm pretty sure I *don't* understand how collation works, or is supposed to work. Amongst other things, I don't understand how (or whether) it handles cases like aa and å, which are considered the same letter in Norwegian. Perhaps you could create a Localization page on wiki.freebsd.org which addresses these issues, or at least points to relevant resources? Good regression test suite which would include cases in different single and multi-byte locates for grep/sort/etc could also be a big help. What regression suites do other implementations have? e.g. the GNU textutils. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Andrey Chernov wrote: On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote: What regression suites do other implementations have? e.g. the GNU textutils. They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform (until Unicode Collation Algorithm will win). OK. Well at least it is a start - passing those existing regression tests should be a goal. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: | Murty, Ravi wrote: | Hello everyone, | | | | Finally found what my last problem was. We were running top in a loop | and running some workloads that called sched_bind() to bind threads to | specific CPUs. The problem was that (and I am using ULE) sched_bind | calls a function to notify another CPU of a thread and then mi_switches | out of it. Since mi_switch sets the oncpu field of the thread to NOCPU | and given the thread is still running, calcru would come in and assert | the fact that If I am running I better no be on NOCPU.. It appears | that in other parts of the kernel (e.g. forward_signal) this is | acceptable (i.e. it is okay to be running and oncpu is NOCPU). | | | Thanks | Ravi | | Don't use ULE in 6.x, it's broken and will not be fixed. Perhaps we should mark it as broken using #error? After all the ULE changes in 7.x is amazing and we do not want to have users to obtain bad impressions from the 6.x versions... I am not sure but some explicit warning message saying ULE has been revamped in FreeBSD 7.x+ and will not be MFC'ed back to 6.x, please use SCHED_4BSD or upgrade to 7.x. seems to be better than having them to pursue the mailing list archive... I would agree with this; if you're happy running unstable and broken scheduler code, you're surely able to update to 7.0 and run stable and working scheduler code :) We should run it past re@ first since it's a change to a stable branch, but it's experimental code so I don't see an issue. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
command-line bittorrent utility
I am looking for a command-line utility that can fetch via bittorrent that a) doesn't use curses. It must be usable in a script and without a tty! b) doesn't use X11. Must be a command-line utility! c) Must be able to inform the script when the transfer is complete. A callback mechanism of some kind is fine as long as it doesn't require polling. This is for distribution of files within a LAN and WAN: I have some large files that I need to distribute to many machines, and pushing them all out multiple times from the server is inefficient. Things that come close: * The python implementation, but it doesn't seem to work very reliably. I get errors and exceptions from both the client and server when transferring a file with only two machines participating. * http://www.murmeldjur.se/btpd/ is a daemon with command line client. It doesn't provide for c), and it also doesn't work reliably. * Not much else. Surely I am not the first person to want to use bittorrent in a script? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: command-line bittorrent utility
Jille Timmermans wrote: (enhanced) ctorrent Seems to fail requirement a). Am I wrong? Kris Kris Kennaway schreef: I am looking for a command-line utility that can fetch via bittorrent that a) doesn't use curses. It must be usable in a script and without a tty! b) doesn't use X11. Must be a command-line utility! c) Must be able to inform the script when the transfer is complete. A callback mechanism of some kind is fine as long as it doesn't require polling. This is for distribution of files within a LAN and WAN: I have some large files that I need to distribute to many machines, and pushing them all out multiple times from the server is inefficient. Things that come close: * The python implementation, but it doesn't seem to work very reliably. I get errors and exceptions from both the client and server when transferring a file with only two machines participating. * http://www.murmeldjur.se/btpd/ is a daemon with command line client. It doesn't provide for c), and it also doesn't work reliably. * Not much else. Surely I am not the first person to want to use bittorrent in a script? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: command-line bittorrent utility
Kris Kennaway wrote: I am looking for a command-line utility that can fetch via bittorrent [...] OK folks, you can stop telling me to use ctorrent now :) I had looked at that but assumed it was using curses (it's not). Thanks! Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: CVSMode for csup with MD5 check
Ulf Lilleengen wrote: Hello, As a followup to my previous patch on csup, I've tried to do some fixes to RCS-files. However, instead of doing major workarounds in csup to handle files which does not behave correctly to RCS, I implemented MD5 check of RCS content. This means that the MD5 sum from cvsupd is checked against the actual RCS content (which is different from a normal MD5 check, because only the content is compared), and if it's not correct, a fixup of the file will be sent, thus making sure that the contents are correct. I hope some of you are able to test this. There are still a few issues with cvsmode: - Not correct entries in status file. - I get unnatural high memory usage. Patches here: http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_CURRENT.diff and http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_RELENG_7.diff This doesn't compile. There are a bunch of warnings, and rcsfile.c is missing from Makefile, but there is an undefined reference: rcsfile.o(.text+0x1d32): In function `rcsfile_frompath': : undefined reference to `rcsparse_run' *** Error code 1 Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impact of having a large number of open file descriptors
Robert Watson wrote: fsevents allows user processes to subscribe, effectively on a per-filesystem basis, to namespace and file close operations. ... I think there's also considerable overlap with other kernel event systems, such as audit, and we might benefit from thinking seriously about enhancing those event systems rather than introducing a new one. The design of fsevents is pretty much entirely dictated by the needs of Spotlight and later Time Machine. In particular, it's not clear to me that the persistency requirements, which are a large part of the fsevents design, are important to us... or are they? Yes, I keep forgetting about audit for some reason :) It might be that this is already good enough for my use case, although having to maintain a path - inode mapping for millions of files will be potentially onerous (same for kevent anyway though). Persistency across reboots for unread events would be nice but probably not essential (or worth the trouble). Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impact of having a large number of open file descriptors
Ivan Voras wrote: Suleiman Souhlal wrote: I have an old patch that makes kqueue monitor every file write on the system and return the inode number in the knote's data field: http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff . I'd think it shouldn't be too hard to make it per-mountpoint.. FWIW, I would love to use this. I have situations where I have huge numbers of files and need to cheaply detect changes so I can resynchronize them to remote machines. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: adding configuration file support to pkg_install
Philip M. Gollucci wrote: Florent Thoumie wrote: This adds support for /etc/pkg.conf configuration file. Also, this adds support for naive multi-site package fetching. Any comment welcome (and appreciated). Patch is here: http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff Tarball is here: http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 Hi flz, I don't quite get what the end goal is. It looks like /etc/pkg.conf is duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. Would not it be better to just have the pkg_install tools read that file instead ? packages are usually built from the ports tree, but not always, and users may use packages without a ports tree present on the local system. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary compatibility query
Carl Shapiro wrote: FreeBSD Hackers, I have a general question about the compatibility of FreeBSD binaries within major releases. If I build a binary for a given release of FreeBSD can I make a reasonable guarantee that the binary will run on both previous and subsequent minor releases of the same major release? In other words, if I build on FreeBSD 6.3 and do not rely on anything unique to 6.3 (such as the presence of specific version strings) how certain can I be that the code will or will not run on 6.2, 6.1 etc.? Also, is this documented anywhere on the FreeBSD web site? The closest thing I could find is the following guidance for driver vendors which falls just short of answering my question: http://wiki.freebsd.org/VendorInformation (Too bad the fancy illustration is missing.) Binaries compiled on a certain version of FreeBSD will continue to run on later versions, but are not guaranteed to run on earlier versions (and in fact *will* not run depending on the binary). This is because over time the system libraries and kernel grow new features which may be used by applications, so they will therefore fail to run if executed on old systems that do not provide these features. If your goal is to provide an application that runs on a range of FreeBSD versions, then either build it for the oldest of these versions, or provide multiple versions if there is a reason to do so (e.g. if there have been major improvements in the OS that are relevant to your application). Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary compatibility query
Daniel Eischen wrote: Binaries compiled on a certain version of FreeBSD will continue to run on later versions, but are not guaranteed to run on earlier versions (and in fact *will* not run depending on the binary). This is because over time the system libraries and kernel grow new features which may be used by applications, so they will therefore fail to run if executed on old systems that do not provide these features. For 7.0 and onwards, we will hopefully have a tool that you can run on your application to do abi checking. One of the things it should be able to do is tell under what releases it will run, including previous releases. That sounds like a good idea! For 6.x, you may be able to manually check the symbols your application uses against the libraries from 6.0, 6.1, etc. This should give a good idea as to whether your application will run on those releases. I think checking symbols is good enough for releases within a branch since we don't change ABIs. Yeah, this should be enough for almost all cases. There are some aspects of the ABI that are not covered by library symbols though, such as file formats, the sysctl MIB, device ioctls, probably others. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary compatibility query
Julian Elischer wrote: Kris Kennaway wrote: Carl Shapiro wrote: FreeBSD Hackers, I have a general question about the compatibility of FreeBSD binaries within major releases. If I build a binary for a given release of FreeBSD can I make a reasonable guarantee that the binary will run on both previous and subsequent minor releases of the same major release? In other words, if I build on FreeBSD 6.3 and do not rely on anything unique to 6.3 (such as the presence of specific version strings) how certain can I be that the code will or will not run on 6.2, 6.1 etc.? Also, is this documented anywhere on the FreeBSD web site? The closest thing I could find is the following guidance for driver vendors which falls just short of answering my question: http://wiki.freebsd.org/VendorInformation (Too bad the fancy illustration is missing.) Binaries compiled on a certain version of FreeBSD will continue to run on later versions, but are not guaranteed to run on earlier versions (and in fact *will* not run depending on the binary). This is because over time the system libraries and kernel grow new features which may be used by applications, so they will therefore fail to run if executed on old systems that do not provide these features. If your goal is to provide an application that runs on a range of FreeBSD versions, then either build it for the oldest of these versions, or provide multiple versions if there is a reason to do so (e.g. if there have been major improvements in the OS that are relevant to your application). I agree in general, however we do make an attempt to keep ABI compatibility within a release line, so that there is a high probability that a binary compiled on a later one will run on an earlier one as long as it does not rely on new features. Actually we don't attempt to keep this form of ABI compatibility (running 6.3 binaries on 6.0, for example), because it basically precludes ever adding new functions to libc within a branch, or new syscalls to the kernel. You are correct that often binaries will not notice these accumulated changes though, or can be carefully constructed to avoid them. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary compatibility query
Carl Shapiro wrote: If my binary only executes system calls indirectly through libc interfaces, as far as libc and libm are concerned, are new symbols the only thing I need to worry about? I think so, yes. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cron(8) related summer of code project
Pavel Prokharau wrote: I was thinking about updating our cron(8) implementation. This project is mentioned in ideas list http://www.freebsd.org/projects/ideas/#p-cron-and-atrun. For now my proposal is following: * update the code base to ISC (OpenBSD already has it for a while) * incorporate changes other BSDs has. First of all it's trivial security fixes OpenBSD has (like strcpy - strlcpy) * atrun(8) improvements as mentioned on ideas page * add privilege separation to cron(8). Its code base is really old and likely to have security bugs. I'd like this work to be done a summer of code project. But I'm not sure if amount of work proposed sufficient for summer of code. If you have some ideas about further improvements to cron(8) I'd be glad hear them and work on it. I think these are good ideas but as you say it doesn't sound like 3 months worth of work. If you would like to submit a proposal relating to this project I think you will need to propose additional tasks to meet the length expectation. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Summer of Code 2008 Project Ideas
Robert Watson wrote: On Mon, 17 Mar 2008, Murray Stokely wrote: The FreeBSD Project was again accepted as a mentoring organization for the Google Summer of Code. The student application period will begin next week so if you have any ideas for great student projects, please send them to [EMAIL PROTECTED] or post them here for discussion. A good student project has a well defined purpose, some key FreeBSD developers that could be identified as potential mentors, and is feasible for a student to complete in a few months time. The existing ideas list is available here : http://www.freebsd.org/projects/ideas/ If you can suggest something (getting specific parts of valgrind working on FreeBSD?) then please provide information in the form of the other projects listed on the page as far as difficulty level, requirements, etc.. FYI, to students considering doing projects -- in the last day or two, we've made significant updates to the project ideas list. If you looked a few days ago, please look again. In particular, we've flagged a large number of potential SoC projects that were not there previously. We've also filtered out some that looked too big to be a good 3-month summer project, although you can still find many on the full ideas list. If you're going to work on a proposal for one of these projects, please directly contact the contacts listed for the project to get feedback before submitting your proposal. We will continue to update the project ideas page as new ideas come in, so do keep checking back. Also, keep in mind that you can submit more than one application if there are multiple projects you find interesting (or we add some later). You can also come up with your own project ideas if we have missed one :) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Matthew Dillon wrote: : Well, I don't think I would agree with your assessment but, : particularly, the way vkernels are implemented in DragonFly is NOT : in the least disruptive to kernel source. : :I was referring to the decision you made to rename all of the kernel :functions that conflicted with libc functions so that vkernels could be :linked against libc. : :Kris Huh. Well, that's about the last thing I would have thought would be considered disruptive to the kernel source. I don't think there's an issue that needs solving, GCC has -nostdlib and -fno-builtin for precisely this reason. Anyway, I agree that this is the least of someone's worries during a hypothetical port of the dragonfly vkernel code. Just so everyone is clear, the scope of such an effort would not be port the code, it would be port the code and also finish it. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Maslan wrote: Hi all, Aren't we working on a FreeBSD/Xen port ??? I think we don't need a Linux like KVM or DragonFly's vkernel, if we could run FreeBSD in dom0. I agree that people interested in virtualization will get the most return on investment if they contribute to the Xen port, large amounts of which are complete. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Matthew Dillon wrote: :I don't think there's an issue that needs solving, GCC has -nostdlib and :-fno-builtin for precisely this reason. You are missing the point entirely. The point is to allow the vkernel to use libc, aka allow it to be compiled, linked, and run as a normal user process. What is your rationale for trying to bypass libc? Why is it so important to you that the kernel retain all those conflicting symbols when it takes literally just an hour of work to fix all the conflicts? If your goal is to link vkernels with libc then by definition you are forced to resolve the namespace conflicts, but I don't see this as a necessary goal. A minimal standalone libkernel would do the same thing without requiring global changes to the kernel namespace, which would likely cause a lot of downstream angst for users of FreeBSD kernel code, providers of third party modules, etc. It seems pretty hard to justify that level of disruption. :Anyway, I agree that this is the least of someone's worries during a :hypothetical port of the dragonfly vkernel code. Just so everyone is :clear, the scope of such an effort would not be port the code, it :would be port the code and also finish it. : :Kris Jeeze, you make it sound like it is some incomplete mess when it is far, far from that. The vkernel is complete, the APIs are complete. It isn't finished in the sense that certain aspects of it, primarily the 'disk' emulation, is not very well optimized, but you are doing the work an extreme disservice by belittling it with undeserving labels. What is the undeserving label? You agree that the code is not finished. In your previous emails you yourself gave a long discussion of changes that would need to be made to bring reasonable performance to various aspects of the vkernel code. I am not discouraging anyone from contributing to that work either in the context of the FreeBSD project or the Dragonfly project; on the contrary we are both pointing out that there is work that needs to be done by someone. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Matthew Dillon wrote: I guess my problem is that you are holding this up as a red flag when it isn't even remotely close to being one. What I have said is that the dragonfly vkernel work is the interesting beginning of a project, but that further work needs to be done before the project is finished in the sense of having reasonable performance, and anyone approaching a FreeBSD port needs to be aware of the scope of the work needed. If you feel that is belittling you, then I'll have to beg your indulgence for not also donning a miniskirt and pompoms. Now that's an image I bet you all weren't expecting. Hah! :-D Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Jordan Gordeev wrote: Hello! I am a student who considers applying for Google's Summer of Code programme. One of my ideas for a GSoC project has the following synopsis: Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64 architectures. The vkernel support in question is the one found in DragonFlyBSD. I wonder if vkernel support would have its place among the myriad of virtualisation technologies, and if it would aid kernel hackers in their kernel development work. I also wonder if anybody would be interested in mentoring this. There are some important things to be aware of with Dragonfly's vkernel. Firstly, while Matt brought it to the point where it works to the extent of booting, being able to recompile kernels, etc, it was never optimized for performance. Dragonfly vkernels are *slow*, even relative to dragonfly non-vkernels which are already much slower than FreeBSD kernels across the board. In this sense it is not a complete project, and what remains to be done is the harder part of the work. It has also not been seriously stress-tested (in part because it is not production quality, but also because it has few users), so there may be a lot of bug fixing required to stabilize the code. Secondly, I don't know to what extent the vkernel work is multi-processor ready, but given that SMP support has also not been a priority for dragonfly there may well be large amounts of SMP work needed to integrate with FreeBSD. Any multi-processor synchronization present would likely have to be reimplemented for FreeBSD anyway due to the different architectural models. None of these issues are being actively worked on in dragonfly, as far as I know. Finally, the way vkernels were implemented in dragonfly was *very* disruptive to the kernel source (lots of function renaming etc), so it is likely that this would also have to be completely reimplemented in a FreeBSD port. The bottom line is that while vkernel is an interesting beginning of a project, it is not a complete piece of code that is suitable for porting to FreeBSD in its present form, and that doesn't seem likely to change in the forseeable future. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Matthew Dillon wrote: :Finally, the way vkernels were implemented in dragonfly was *very* :disruptive to the kernel source (lots of function renaming etc), so it :is likely that this would also have to be completely reimplemented in a :FreeBSD port. :... :Kris Well, I don't think I would agree with your assessment but, particularly, the way vkernels are implemented in DragonFly is NOT in the least disruptive to kernel source. I was referring to the decision you made to rename all of the kernel functions that conflicted with libc functions so that vkernels could be linked against libc. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel crash on Asus A7N8X-X
Frédéric PRACA wrote: Hello dear hackers, I own a Asus A7N8X-X motherboard (NForce2 chipset) with a Radeon 9600 video card. After upgrading from 6.3 to 7.0, I launched xorg which crashed the kernel. After looking in the kernel core dump, I found that the agp_nvidia_flush_tlb function of /usr/src/sys/pci/agp_nvidia.c crashed on the line 377. The loop fails from the beginning (when i==0). I commented out the two last loops and it seems to work now but as I didn't understand what is this code for, I'd like to have some explanation about it and want to know if someone got the same problem. Usually it's a good idea to show the data that led to your conclusions (backtraces, etc), not just your conclusions. Sometimes there is more going on than is immediately apparent. Krs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about http://torrents.freebsd.org:8080/index.html
Sean Bruno wrote: Does it seem correct to all concerned that each release actually lists all files twice? There is a torrent for the entire release CD ISO set, and then there is a completely separate torrent for each CD ISO file. At least that is what it looks like to me. Is this correct? Yes. Many people like to download the whole thing in one torrent. It does split the aggregate swarm bandwidth, but it doesn't seem to be a problem in practice. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: Greetings, Kris Kennaway wrote: Kris Kennaway wrote: Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so that is the next place to look. [hit send too soon] Actually 15MB/sec once I disable all kernel debugging. This is identical to Linux 2.6.24 on the same hardware. The patch I use to fix hping brain-damage is attached. Kris Indeed this patch highly improve results (x2) under FreeBSD. On my hardware the max speeds under FreeBSD i still little slower compared to Linux (something like 19 vs 19.5 MB/s) but the speed is quite more stable under FreeBSD (under linux the average speed seems slower) I didn't tested the patch under linux but will do soon. Thanks for the help :) BTW 262144 is little high as this match the default value in FreeBSD, I tested with twice smaller buffer and do not see performance lost. Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? My patch is a bit crude, because I didnt have the courage to digest the entire structure of the code, so it may be slightly wrong with respect to other operating modes (the #if 0 part is wrong, but that code needs to be rewritten). Some version of it should be included in the software, but perhaps after renaming the patch file ;-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
Xin LI wrote: I can not speak for that, but my understanding is, no, it won't be MFC'ed. The performance enhancements on 7.x included a lot of factors, ULE is one of them, and there are also some other enhancements in the system, which could be not suitable for MFC due to ABI/KBI change. Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: FreeBSD - ACPI em1 in 13.157 MB/s 13.162 MB/s 23.697 GB out13.150 MB/s 13.153 MB/s 17.976 GB FreeBSD - TSC em1 in 18.624 MB/s 18.832 MB/s 25.507 GB out17.008 MB/s 17.041 MB/s 19.681 GB FreeBSD - i8254 em1 in 6.763 MB/s 6.763 MB/s 26.005 GB out 6.756 MB/s 6.758 MB/s 20.151 GB FreeBSD - dummy em1 in 18.705 MB/s 18.796 MB/s 27.014 GB out17.217 MB/s 17.225 MB/s 21.082 GB I forgot to mention I was using -a to spoof the return address so time is not wasted receiving packets (since your goal was to syn flood the server). Probably there are other (possibly also bogus) gettimeofday calls that are still present in hping when receiving packets. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
[EMAIL PROTECTED] wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) All right, I won't :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. I can hear you. Then again, I'm in the slow process of converting people in my office to use FreeBSD instead of GNU/Linux: it's not going to be easy if 6.3 4BSD exhibits slownesses when compiling a kernel, and 6.3 ULE might prove not that stable :-\ (I've not encountered any problem until now, though, and I'm touching wood as my granny says) By the way, why still include ULE in 6.x if it is to be avoided ? Typically we don't remove even experimental (even broken) code in stable branches in case it is still useful to someone despite the problems. Try 7.0 instead. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Kris Kennaway wrote: Stefan Lambrev wrote: I run from host A : hping --flood -p 22 -S 10.3.3.2 and systat -ifstat on host B to see the traffic that is generated (I do not want to run this monitoring on the flooder host as it will effect his performance) OK, I finally got time to look at this. Firstly, this is quite an inefficient program. It performs 5 syscalls for each packet that it sends: 2391 initial thread CALL sendto(0x3,0x61b050,0x28,0,0x5232c0,0x10) 2391 initial thread GIO fd 3 wrote 40 bytes 0x 4500 2800 7491 4006 0a00 0004 0a00 0001 3a96 0016 1865 a781 39d8 12aa 5002 0200 52c9 |E.([EMAIL PROTECTED]:e..9...P...R.| 0x0026 |..| 2391 initial thread RET sendto 40/0x28 2391 initial thread CALL sigaction(SIGALRM,0x7fffe6b0,0x7fffe690) 2391 initial thread RET sigaction 0 2391 initial thread CALL setitimer(0,0x7fffe6c0,0x7fffe6a0) 2391 initial thread RET setitimer 0 2391 initial thread CALL gettimeofday(0x7fffe680,0) 2391 initial thread RET gettimeofday 0 2391 initial thread CALL gettimeofday(0x7fffe680,0) 2391 initial thread RET gettimeofday 0 Here is a further litany of some of the ways in which this software is terrible: * It does not attempt to increase the socket buffer size (as we have already discussed), but * It also doesn't cope with the possibility that the packet may not be sent because the send buffer is full. * With every packet sent in flood mode it sets a timer for 1 second in the future even though we have told it not to send packets once a second but as fast as possible * We also set the signal handler with each packet sent, instead of setting it once and leaving it. * We call gettimeofday twice for each packet, once to retrieve the second timestamp and once to retrieve the microseconds. This is only for the purpose of computing the RTT. However, we can only keep track of 400 in-flight packets, which means this is also useless in flood mode. * The suspend handler does not work * This does not strike me as quality software :) Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so that is the next place to look. [hit send too soon] Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Kris Kennaway wrote:
Fixing all of the above I can send at about 13MB/sec (timecounter is
not relevant any more). The CPU is spending about 75% of the time in
the kernel, so
that is the next place to look. [hit send too soon]
Actually 15MB/sec once I disable all kernel debugging. This is
identical to Linux 2.6.24 on the same hardware. The patch I use to fix
hping brain-damage is attached.
Kris
diff -ru work/hping3-20051105/opensockraw.c work~/hping3-20051105/opensockraw.c
--- opensockraw.c.orig 2003-09-01 00:22:06.0 +
+++ opensockraw.c 2008-02-03 19:45:28.0 +
@@ -17,7 +17,7 @@
int open_sockraw()
{
- int s;
+ int s, t, val;
s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
if (s == -1) {
@@ -25,5 +25,12 @@
return -1;
}
+ val = 262144;
+ t = setsockopt(s, SOL_SOCKET, SO_SNDBUF, val, sizeof(val));
+ if (t == -1) {
+ perror([open_sockraw] setsockopt());
+ return -1;
+ }
+
return s;
}
diff -ru work/hping3-20051105/sendip.c work~/hping3-20051105/sendip.c
--- sendip.c.orig 2004-04-09 23:38:56.0 +
+++ sendip.c2008-02-03 19:50:35.0 +
@@ -110,7 +110,7 @@
result = sendto(sockraw, packet, packetsize, 0,
(struct sockaddr*)remote, sizeof(remote));
- if (result == -1 errno != EINTR !opt_rand_dest
!opt_rand_source) {
+ if (result == -1 errno != ENOBUFS errno != EINTR
!opt_rand_dest !opt_rand_source) {
perror([send_ip] sendto);
if (close(sockraw) == -1)
perror([ipsender] close(sockraw));
diff -ru work/hping3-20051105/sendtcp.c work~/hping3-20051105/sendtcp.c
--- sendtcp.c.orig 2003-09-01 00:22:06.0 +
+++ sendtcp.c 2008-02-03 20:30:51.0 +
@@ -85,8 +85,10 @@
packet_size);
#endif
+#if 0
/* adds this pkt in delaytable */
delaytable_add(sequence, src_port, time(NULL), get_usec(), S_SENT);
+#endif
/* send packet */
send_ip_handler(packet+PSEUDOHDR_SIZE, packet_size);
--- send.c.orig 2003-08-31 17:23:53.0 +
+++ send.c 2008-02-03 21:58:59.0 +
@@ -63,6 +63,8 @@
}
}
+static int sigalarm_handler = 0;
+
/* The signal handler for SIGALRM will send the packets */
void send_packet (int signal_id)
{
@@ -79,12 +81,15 @@
elsesend_tcp();
sent_pkt++;
- Signal(SIGALRM, send_packet);
+ if (!opt_flood !sigalarm_handler) {
+ Signal(SIGALRM, send_packet);
+ sigalarm_handler = 1;
+ }
if (count != -1 count == sent_pkt) { /* count reached? */
Signal(SIGALRM, print_statistics);
alarm(COUNTREACHED_TIMEOUT);
- } else if (!opt_listenmode) {
+ } else if (!opt_listenmode !opt_flood) {
if (opt_waitinusec == FALSE)
alarm(sending_wait);
else
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory allocation performance
Alexander Motin wrote: Robert Watson wrote: Hence my request for drilling down a bit on profiling -- the question I'm asking is whether profiling shows things running or taking time that shouldn't be. I have not yet understood why does it happend, but hwpmc shows huge amount of p4-resource-stalls in UMA functions: For this moment I have invent two possible explanation. One is that due to UMA's cyclic block allocation order it does not fits CPU caches and another that it is somehow related to critical_exit(), which possibly can cause context switch. Does anybody have better explanation how such small and simple in this part function can cause such results? You can look at the raw output from pmcstat, which is a collection of instruction pointers that you can feed to e.g. addr2line to find out exactly where in those functions the events are occurring. This will often help to track down the precise causes. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory allocation performance
Alexander Motin wrote: Kris Kennaway пишет: Alexander Motin wrote: Alexander Motin пишет: While profiling netgraph operation on UP HEAD router I have found that huge amount of time it spent on memory allocation/deallocation: I have forgotten to tell that it was mostly GENERIC kernel just built without INVARIANTS, WITNESS and SMP but with 'profile 2'. What is 'profile 2'? I have thought it is high resolution profiling support. Isn't it? OK. This is not commonly used so I don't know if it works. Try using hwpmc if possible to compare. When you say that your own allocation routines show less time use under profiling, how do they affect the actual system performance? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory allocation performance
Alexander Motin wrote: Hi. While profiling netgraph operation on UP HEAD router I have found that huge amount of time it spent on memory allocation/deallocation: 0.14 0.05 132119/545292 ip_forward cycle 1 [12] 0.14 0.05 133127/545292 fxp_add_rfabuf [18] 0.27 0.10 266236/545292 ng_package_data [17] [9]14.1 0.56 0.21 545292 uma_zalloc_arg [9] 0.17 0.00 545292/1733401 critical_exit cycle 2 [98] 0.01 0.00 275941/679675 generic_bzero [68] 0.01 0.00 133127/133127 mb_ctor_pack [103] 0.15 0.06 133100/545266 mb_free_ext [22] 0.15 0.06 133121/545266 m_freem [15] 0.29 0.11 266236/545266 ng_free_item [16] [8]15.2 0.60 0.23 545266 uma_zfree_arg [8] 0.17 0.00 545266/1733401 critical_exit cycle 2 [98] 0.00 0.04 133100/133100 mb_dtor_pack [57] 0.00 0.00 134121/134121 mb_dtor_mbuf [111] I have already optimized all possible allocation calls and those that left are practically unavoidable. But even after this kgmon tells that 30% of CPU time consumed by memory management. So I have some questions: 1) Is it real situation or just profiler mistake? 2) If it is real then why UMA is so slow? I have tried to replace it in some places with preallocated TAILQ of required memory blocks protected by mutex and according to profiler I have got _much_ better results. Will it be a good practice to replace relatively small UMA zones with preallocated queue to avoid part of UMA calls? 3) I have seen that UMA does some kind of CPU cache affinity, but does it cost so much that it costs 30% CPU time on UP router? Make sure you have INVARIANTS disabled, it has a high performance cost in UMA. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory allocation performance
Alexander Motin wrote: Alexander Motin пишет: While profiling netgraph operation on UP HEAD router I have found that huge amount of time it spent on memory allocation/deallocation: I have forgotten to tell that it was mostly GENERIC kernel just built without INVARIANTS, WITNESS and SMP but with 'profile 2'. What is 'profile 2'? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Joseph Koshy wrote: OK, this is the famous problem with modern CPUs that jkoshy has declined to work around :( There are patches for this in perforce, see http://perforce.freebsd.org/changeView.cgi?CH=126189 Famous problem indeed :). I declined the patch because it is incorrect and incomplete. I will accept a patch that demonstrates clue about the workings of the overall system---the changes in the patch should be safe, complete, should demonstrate that the submitter has read and understood vendor documentation, should preserve user experience for naming events, and each supported PMC event needs to be documented in pmc.3. I am aware of these issues but repeat my statement that the lack of working pmc on modern CPUs is causing serious difficulties for our developer and user base, as witnessed again in this thread. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: You also need changes to the userland libpmc and pmcstat. They should also be in that (or related) p4 changeset though. Those are the files that I fetched from p4 /usr/src/lib/libpmc/libpmc.c - rev2 /usr/src/sys/amd64/include/pmc_mdep.h rev2 /usr/src/sys/dev/hwpmc/hwpmc_x86.c rev2 /usr/src/sys/modules/hwpmc/Makefile rev3 but I rebuild only kernel - I'll try to rebuild everything :) do you think this will help getting hwpmc working? I can only say that it mostly works for me :) Btw I have hwpmc working on other machine (it's with FreeBSD 6.3-prerelease). Can you tell me what stats exactly you need from running hping? A gprof trace with the -S instructions counter should be enough to get oriented. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: Hi Kris, Kris Kennaway wrote: Stefan Lambrev wrote: Kris Kennaway wrote: Stefan Lambrev wrote: You should use hwpmc to verify where the application is really spending time, since gettimeofday doesn't seem to account for it all. pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x8029906d, 0x8054c500) error 78 OK, this is the famous problem with modern CPUs that jkoshy has declined to work around :( There are patches for this in perforce, see http://perforce.freebsd.org/changeView.cgi?CH=126189 I got hwpmc to compile (but only as module) hwpmc: TSC/1/0x20REA P6/2/0x1ffINT,USR,SYS,EDG,THR,REA,WRI,INV,QUA but when I try to use pmcstat I receive this error message: pmcstat: ERROR: Initialization of the pmc(3) library failed: Device not configured kldstat lists hwpmc.ko as loaded and I have options HWPMC_HOOKS in my kernel. Any idea what's go wrong? You also need changes to the userland libpmc and pmcstat. They should also be in that (or related) p4 changeset though. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Ivan Voras wrote: On 23/01/2008, Stefan Lambrev [EMAIL PROTECTED] wrote: Greets, Now I have final results with Linux and FreeBSD on the same hardware CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz - dual core Lan: [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet FreeBSD releng_7_0 from today - amd64, sched_ule. ACPI-Fast - 6.187 MB/s TSC - 9.455 MB/s dummy - 9.577 MB/s Linux rambo2 2.6.22-14-generic #1 SMP Tue Dec 18 05:28:27 UTC 2007 x86_64 GNU/Linux - kubuntu TSC - 19.456 MB/s acpi_pm - 15.394 MB/s jiffies - 19.480 MB/s This is really not what I expected. For once, it's something I expected :) I just hope it isn't one of those cases where Kris absolutely cannot reproduce it and arrives at numbers in favour of FreeBSD :) (just joking here, absolutely no ill feelings involved). Harumph :) The first step is that we need to understand where the application is spending its time. Hopefully Stefan or someone else will be able to test it under hwpmc. It would be helpful if you post exact command line arguments from all cases. The other thing that bothers me is, that under freebsd is quite easy to get: [send_ip] sendto: No buffer space available It happens almost always on my laptop just few seconds after I start hping with timecounter=TSC I'm not sure, but from what I understood of Robert Watson's explanation in the big ZFS thread on -current, maybe increasing kmem_size (exactly as for ZFS...) could help you with these buffers. It is the socket buffer that is filling up. Either the application is not increasing it to large enough size or the default maximum is too low (Linux may set a larger default). Try increasing kern.ipc.maxsockbuf and confirming with the source and/or ktrace that it is doing the right setsockopt() call. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: Hi, Dag-Erling Smørgrav wrote: Stefan Lambrev [EMAIL PROTECTED] writes: I tested all different combination. The performance change is almost invisible (100-200KB/s), and can't be compared with the performance boost that TSC gain over ACPI-fast timecounter. Unfortunately TSC doesn't play nice with power saving modes. This will vary greatly from machine to machine, depending on the exact hardware and the ACPI BIOS. More modern machines have an HPET timer which is supposedly faster than ACPI yet more reliable than TSC. DES I do not have HEPT on the servers that I test, but simple test on my laptop shows that hping can generate with ACPI-fast ~4MB/s traffic, 5MB/s with HPET and 8MB/s with TSC. I didn't check dummy time counter. Also I noticed that there is a kern.timecounter.tc.XXX.quality (read only). Can this be used to reduce quality and speed up performance? No, they are meaningless values only used to rank the time counters and choose one at boot. You should use hwpmc to verify where the application is really spending time, since gettimeofday doesn't seem to account for it all. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: You should use hwpmc to verify where the application is really spending time, since gettimeofday doesn't seem to account for it all. pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x8029906d, 0x8054c500) error 78 OK, this is the famous problem with modern CPUs that jkoshy has declined to work around :( There are patches for this in perforce, see http://perforce.freebsd.org/changeView.cgi?CH=126189 What was the other way to do this profiling? No other that I have found to be useful. Can ktrace help? Not really, it only tells you what syscalls were made. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: How much can Linux handle? Will install ubuntu on the same machine and let you know, but my experience shows that FreeBSD + TSC have the same performance as Linux With which timecounter? Here are the max speeds I can reach with different counters (on the test server): i8254 - 3.660 MB/s ACPI-fast - 7.137 MB/s TSC - 12.519 MB/s dummy - 12.366 MB/s Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: Kris Kennaway wrote: Stefan Lambrev wrote: You should use hwpmc to verify where the application is really spending time, since gettimeofday doesn't seem to account for it all. pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x8029906d, 0x8054c500) error 78 OK, this is the famous problem with modern CPUs that jkoshy has declined to work around :( There are patches for this in perforce, see http://perforce.freebsd.org/changeView.cgi?CH=126189 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror vers.c linking kernel.debug hwpmc_x86.o(.text+0x1a5): In function `pmc_md_initialize': /usr/src/sys/dev/hwpmc/hwpmc_x86.c:144: undefined reference to `pmc_initialize_p6' Any chance you have patches against RELENG_7_0 ? :) They should apply, but maybe you will also need other patches from that branch. What was the other way to do this profiling? No other that I have found to be useful. Can ktrace help? Not really, it only tells you what syscalls were made. But it can also display relative timestamps (time since previous entry). Can't this be useful? Not really, it doesn't give enough of a cross-section into what your machine is spending its time doing. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic while using tcpdump
Bartosz Giza wrote: Hi, We are using a lot of i386 computers as routers for out network. All of those routers are using FreeBSD from 4.x to 7.x (exept 5.x) We are having problem with kernel panic on routers based on 6.x and 7.x while using tcpdump or trafshow. It is not that always we got kernel panics. We got them in random occurence. Some time i can tcpdump for a minute and turn it off and again while i am testing packets comming thru iface for an hour, and nothin happens. But sometime i run tcpdump and after few second i got kernel panic. It happens mostly when i am trying to close tcpdump with ctrl-c. It happens also with trafshow3 which we are using to track transfers. It happens on 6.x series and i thought that maybe there is bug in this line and i have tryied 7.x line i got kernel panics also. The problem is that i can't really get message when it happens because those routers are in remote places and after 15 second they are rebooting (and that is great:) Is there any way to save this message to a file that i could paste over here ? Could some one help me to diagnoze this behaviour ? We are using i386 arch on all routers. The hardware is totally different from quite old parts to quite new dell. What is strange on 4.x we never hit such a kernel panic. We are using mostly fxp NIC on all routers with some exeptions and i have started wondering that maybe fxp driver has some bug or bpf code. Thanks for any help in diagnosing this panics. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Graceful failure instead of panicking in kmem_malloc
Joshua Isom wrote: On Jan 8, 2008, at 9:25 PM, Bharma Ji wrote: Thanks for the response. I am hoping to keep some memory aside specifically for handling out of memory allocation situations. Yes the real fix is to avoid out of memory allocation. Thanks for the patch. Will try that. As a first cut I am just trying to handle failure gracefully. So asking again - if there is any way already discussed or standardized to make the system handle failures gracefully On Jan 8, 2008 4:30 PM, Kris Kennaway [EMAIL PROTECTED] wrote: Bharma Ji wrote: In FreeBSD 6_2, if kmem_malloc is unable to find space it panics. The relevant code is in vm_kern.c if ((flags M_NOWAIT) == 0) panic(kmem_malloc(%ld): kmem_map too small: %ld total allocated, (long)size, (long)map-size); Is there any way to make the system log and then gracefully shut off instead of panicking? Not really, because those actions require memory allocation. The real fix is to either a) avoid running out of memory in the first place by tuning vm.kmem_size b) perhaps trying harder to avoid panicking by first trying to more aggressively reclaim memory. You can try http://www.freebsd.org/~pjd/patches/vm_kern.c.2.patchhttp://www.freebsd.org/%7Epjd/patches/vm_kern.c.2.patch which implements b) (patch against 7.0, but might apply to 6.2 unchanged). Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Why not try to take out some user processes? Going with a combination of process priority and memory usage, it should at least be more tolerable than a panic. This is kernel memory, not user memory. There is a fixed-size arena for mallocs in the kernel, and the panic happens when it fills up and no free space can be immediately reclaimed. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Graceful failure instead of panicking in kmem_malloc
Bharma Ji wrote: In FreeBSD 6_2, if kmem_malloc is unable to find space it panics. The relevant code is in vm_kern.c if ((flags M_NOWAIT) == 0) panic(kmem_malloc(%ld): kmem_map too small: %ld total allocated, (long)size, (long)map-size); Is there any way to make the system log and then gracefully shut off instead of panicking? Not really, because those actions require memory allocation. The real fix is to either a) avoid running out of memory in the first place by tuning vm.kmem_size b) perhaps trying harder to avoid panicking by first trying to more aggressively reclaim memory. You can try http://www.freebsd.org/~pjd/patches/vm_kern.c.2.patch which implements b) (patch against 7.0, but might apply to 6.2 unchanged). Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
prefaulting MAP_ANONYMOUS pages
I am trying to optimize a malloc-based benchmark that is mmapping anonymous memory (via mmap) and then eventually taking a page fault on every page that was allocated. This is pretty inefficient for two reasons: 1) Lots of page faults, which drop performance by a factor of 10 compared to the case where everything is faulted in. 2) Lack of concurrency when faulting from multiple threads on the same object (it is basically serialized, so no benefits from multiple CPUs) I think a better way to go might be to do prefetching to reduce the number of page faults. We do this for other types of mappings, but apparently not for anonymous mmapped memory. I am still trying to get my head around the code here, but it looks like vm_fault_prefault is going to return without doing anything because of while ((m = vm_page_lookup(lobject, pindex)) == NULL ... /* * give-up when a page is not in memory */ Also vm_fault_additional_pages() isn't getting called because TRYPAGER returns false for default objects. Is there a way to achieve this that I am overlooking? If not can someone give me some advice about what is needed? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: prefaulting MAP_ANONYMOUS pages
Kris Kennaway wrote: I am trying to optimize a malloc-based benchmark that is mmapping anonymous memory (via mmap) s/mmap/malloc/ ;) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib/pthread.so.2 is sought during some port compilation
Yuri wrote: Sorry about that. Please find the logs below. My system is upgraded from 6.3. And /lib/libpthread.so.2 is not a symlink. But when I make it a symlink (ln -s /lib/libthr.so.3 /lib/libpthread.so.2) I get another error, see log below. Some requisite libs are compiled with /lib/libpthread.so.2 (?) and now firefox is being compiled with a new libc.so.7. So do I have to rebuild all ports to be able to run on 7.0? Yes. You have to do this whenever you upgrade to a new branch of FreeBSD. The old ports will work until you start upgrading them to new versions, at which point you will end up with binaries linked to two versions of FreeBSD libraries, like libc.so.6 and libc.so.7, and this is a recipe for disaster. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib/pthread.so.2 is sought during some port compilation
Yuri wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: So do I have to rebuild all ports to be able to run on 7.0? Yes. You have to do this whenever you upgrade to a new branch of FreeBSD. The old ports will work until you start upgrading them to new versions, at which point you will end up with binaries linked to two versions of FreeBSD libraries, like libc.so.6 and libc.so.7, and this is a recipe for disaster. Yes, that's what I am doing. portupgrade -af That is what you are doing now, or what you were doing when you found the problem? It should not occur during a portupgrade -af unless there is a port that is missing registration on some dependencies. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TMPFS Implementation for FreeBSD
[EMAIL PROTECTED] wrote: hi , freebsd-hackers. I found this reference http://docs.freebsd.org/cgi/getmsg.cgi?fetch=372365+0+/usr/local/www/db/text/2006/freebsd-hackers/20060226.freebsd-hackers how is it correct to conduct this procedure ? beforehand thank you !! tmpfs is included in FreeBSD 7.0. It still has some known problems, but might be stable enough for light use. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib/pthread.so.2 is sought during some port compilation
Yuri wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: Yes, that's what I am doing. portupgrade -af That is what you are doing now, or what you were doing when you found the problem? It should not occur during a portupgrade -af unless there is a port that is missing registration on some dependencies. Kris That's what I am doing now. When the original problem occurred I was just running 'portupgrade -aP' which was wrong on freshly upgraded to 7.0 machine. OK, cool. Good luck :) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib/pthread.so.2 is sought during some port compilation
Yuri wrote: I tried to compile firefox-2.0.0.10 on 7.0-BETA3. And one linking command failed seeking for malloc_lock symbol required by /lib/pthread.so.2. Obviously it tried to link obsolete /lib/pthread.so.2 with the new /lib/libc.so.7. By reading /usr/src/UPDATING I learn that the default threading library has been replaced by /lib/libthr.so. Why would linker seek for libpthread.so instead of libthr.so? libpthread is a symlink to libthr on a correctly functioning FreeBSD 7.0 installation. In general, when you encounter a problem you need to cut and paste the exact errors, instead of typing from memory and getting it wrong (there is no /lib/pthread.so.2, etc). Showing us the errors mean that we are more likely to understand your problem and help you to fix it. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Before After Under The Giant Lock
[EMAIL PROTECTED] wrote: Hello, Quoting Robert Watson [EMAIL PROTECTED]: No problem -- just to be clear: in 7, users can still choose between libpthread (m:n) and libthr (1:1), but the default is now libthr rather than libpthread, as libthr seemed to perform better in most if not all workloads of interest. I thought 1:1 would perform better with I/O bound processes running several threads. But wouldn't a process rely on a few I/O threads for several other CPU bound threads ? (unless specific activities such as a web server, or a database, which would explain MySQL performing better with 1:1) Or, to make my point (somewhat) clearer: how did you actually compare advantages of 1:1 versus M:N when the change from the latter to the former was decided ? We took a look at performance of the 1:1 implementation compared to M:N and noticed that the latter was completely terrible. As in: slower and less scalable by 2 orders of magnitude -- on every workload we could find (except for one highly contrived microbenchmark). M:N was a nice idea and maybe it could have been improved with a lot of work, but in practise no-one was able to make performance not suck. And second question: would it be possible to dynamically choose one way over the other: meaning if you know you're mostly I/O bound, then request for the 1:1 type of threads, and vice versa ? If you really really really (really) want to use the M:N libkse, you can use libmap to control it per-binary. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Kris Kennaway wrote: what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by Patrol Reads where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc gg port. Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Wow! Really disabling Patrol Reads solves the problem. Thank you! I have many amrd's and all of them appear to have Patrol Reads enabled by default. But the problem happenes only on three of them. Is this a hardware problem? I am not sure, maybe for some reason the patrol reads are not interfering with other disk I/O so much (e.g. the hardware prioritises them differently or something). Anyway, glad to hear it was resolved. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Kris Kennaway wrote: Alexey Popov wrote: Hi. Panagiotis Christias wrote: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. I don't know what this graph is showing me :) When precisely is the system behaving poorly? what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. ** Existing Logical Drive Information By LSI Logic Corp.,USA ** [Note: For SATA-2, 4 and 6 channel controllers, please specify Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)] Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL --- SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: DirectIo StripSz :064KB Stripes : 6 WrPolicy: WriteBack Logical Drive 0 : SpanLevel_0 Disks Chnl Target StartBlock Blocks Physical Target Status -- -- -- -- 0 000x 0x22ec ONLINE 0 010x 0x22ec ONLINE 0 020x 0x22ec ONLINE 0 030x 0x22ec ONLINE 0 040x 0x22ec ONLINE 0 050x 0x22ec ONLINE I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by Patrol Reads where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc port. Kris Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi. Panagiotis Christias wrote: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. I don't know what this graph is showing me :) When precisely is the system behaving poorly? what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. ** Existing Logical Drive Information By LSI Logic Corp.,USA ** [Note: For SATA-2, 4 and 6 channel controllers, please specify Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)] Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL --- SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: DirectIo StripSz :064KB Stripes : 6 WrPolicy: WriteBack Logical Drive 0 : SpanLevel_0 Disks Chnl Target StartBlock Blocks Physical Target Status -- -- -- -- 0 000x 0x22ec ONLINE 0 010x 0x22ec ONLINE 0 020x 0x22ec ONLINE 0 030x 0x22ec ONLINE 0 040x 0x22ec ONLINE 0 050x 0x22ec ONLINE I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by Patrol Reads where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc port. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi. Kris Kennaway wrote:te: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. With best regards, Alexey Popov I don't know what this graph is showing me :) When precisely is the system behaving poorly? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2 Crash
Atanas Gendov wrote: Hi all FreeBSD Hackers! :) My FreeBSD auto reboot itself and I got this report by kgdb, but actually I'm not a programmer. I don't know how to debug this error. Could someone helps with fixing? Thanx in advanced! FreeBSD .com 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #0: Tue Oct 30 22:54:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THURISAZ i386 kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0489471 esp = 0xd568af78 ebp = 0xd568b094 panic: double fault Do you use the nve driver? It has a known bug that causes a double fault. Unfortunately kgdb doesn't know how to properly decode double fault backtraces, so there isn't any more information about the cause. If you are not using nve, can you try to reproduce and then see what DDB says about the backtrace? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi Kris Kennaway wrote: So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. pmc would be useful. pmc profiling attached. OK, the pmc traces do seem to show that it's not a lock contention issue. That being the case I don't think the fact that different servers perform better is directly related. But it was evidence of mbuf lock contention in mutex profiling, wasn't it? As far as I understand, mutex problems can exist without increasing CPU load in pmc stats, right? No, the lock functions will show up as using a lot of CPU. I guess the lock profiling trace showed high numbers because you ran it for a long time. There is also no evidence of a VM problem. What your vmstat and pmc traces show is that your system really isn't doing much work at all, relatively speaking. There is also still no evidence of a disk problem. In fact your disk seems to be almost idle in both cases you provided, only doing between 1 and 10 operations per second, which is trivial. vmstat and network output graphs shows that the problem exists. If it is not a disk or network or VM problem, what else could be wrong? The vmstat output you provided so far doesn't show anything specific. In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. I'll try this, but AFAIR there was no strangeness with interrupts. I believe the reason of high interrupt rate in good cases is that server sends much traffic. What there is evidence of is an interrupt aliasing problem between em and USB: irq16: uhci0 1464547796 1870 irq64: em01463513610 1869 I tried disabling USB in kernel, this ussie was gone, but the main problem was left. Also I have this issue with interrupt aliasing on many servers without problems. OK. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi Kris Kennaway wrote: So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. pmc would be useful. pmc profiling attached. Sorry for the delay, I was travelling last weekend and it took a few days to catch up. OK, the pmc traces do seem to show that it's not a lock contention issue. That being the case I don't think the fact that different servers perform better is directly related. In my tests multithreaded web servers don't seem to perform well anyway. There is also no evidence of a VM problem. What your vmstat and pmc traces show is that your system really isn't doing much work at all, relatively speaking. There is also still no evidence of a disk problem. In fact your disk seems to be almost idle in both cases you provided, only doing between 1 and 10 operations per second, which is trivial. In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. What there is evidence of is an interrupt aliasing problem between em and USB: irq16: uhci0 1464547796 1870 irq64: em01463513610 1869 This is a problem on some intel systems. Basically each em0 interrupt is also causing a bogus interrupt to the uhci0 device too. This will be causing some overhead and might be contributing to the UMA problems. I am not sure if it is the main issue, although it could be. It is mostly serious when both irqs run under Giant, because they will both fight for it every time one of them interrupts. That is not the case here but it could be other bad scenarios too. You could try disabling USB support in your kernel since you dont seem to be using it. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: This is very unlikely, because I have 5 another video storage servers of the same hardware and software configurations and they feel good. Clearly something is different about them, though. If you can characterize exactly what that is then it will help. I can't see any difference but a date of installation. Really I compared all parameters and got nothing interesting. At first glance one can say that problem is in Dell's x850 series or amr(4), but we run this hardware on many other projects and they work well. Also Linux on them works. OK but there is no evidence in what you posted so far that amr is involved in any way. There is convincing evidence that it is the mbuf issue. Why are you sure this is the mbuf issue? Because that is the only problem shown in the data you posted. For example, if there is a real problem with amr or VM causing disk slowdown, then when it occurs the network subsystem will have another load pattern. Instead of just quick sending large amounts of data, the system will have to accept large amount of sumultaneous connections waiting for data. Can this cause high mbuf contention? I'd expect to see evidence of the main problem. And few hours ago I received feed back from Andrzej Tobola, he has the same problem on FreeBSD 7 with Promise ATA software mirror: Well, he didnt provide any evidence yet that it is the same problem, so let's not become confused by feelings :) I think he is telling about 100% disk busy while processing ~5 transfers/sec. % busy as reported by gstat doesn't mean what you think it does. What is the I/O response time? That's the meaningful statistic for evaluating I/O load. Also you didnt post about this. So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. pmc would be useful. Also now I run nginx instead of lighttpd on one of the problematic servers. It seems to work much better - sometimes there is a peaks in disk load, but disk does not become very slow and network output does not change. The difference of nginx is that it runs in multiple processes, while lighttpd by default has only one process. Now I configured lighttpd on other server to run in multiple workers. I'll see if it helps. What else can i try? Still waiting on the vmstat -z output. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Kris Kennaway wrote: What else can i try? Still waiting on the vmstat -z output. Also can you please obtain vmstat -i, netstat -m and 10 seconds of representative vmstat -w output when the problem is and is not occurring? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi. Kris Kennaway wrote: After some time of running under high load disk performance become expremely poor. At that periods 'systat -vm 1' shows something like this: What does high load mean? You need to explain the system workload more. This web service is similiar to YouTube. This server is video store. I have around 200G of *.flv (flash video) files on the server. I run lighttpd as a web server. Disk load is usually around 50%, network output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. As you can see it is a trivial service - sending files to network via HTTP. A couple of comments. Does lighttpd actually use HTTP accept filters? Are you using ipfilter and ipfw? You are paying a performance penalty for having them. You might try increasing BUCKET_MAX in sys/vm/uma_core.c. I don't really understand the code here, but you seem to be hitting a threshold behaviour where you are constantly running out of space in the per CPU caches. This can happen if your workload is unbalanced between the CPUs and you are always allocating on one but freeing on another, but I wouldn't expect it should happen on your workload. Maybe it can also happen if your turnover is high enough. What does vmstat -z show during the good and bad times? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi. Kris Kennaway wrote: After some time of running under high load disk performance become expremely poor. At that periods 'systat -vm 1' shows something like this: What does high load mean? You need to explain the system workload more. This web service is similiar to YouTube. This server is video store. I have around 200G of *.flv (flash video) files on the server. I run lighttpd as a web server. Disk load is usually around 50%, network output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. As you can see it is a trivial service - sending files to network via HTTP. Does lighttpd actually use HTTP accept filters? Don't know how to make sure, but is seems to run appropriate setsockopt (truss output): setsockopt(0x4,0x,0x1000,0x7fffe620,0x100) = 0 (0x0) OK. Are you using ipfilter and ipfw? You are paying a performance penalty for having them. I'm using ipfw and one of the first rules is to pass all TCP established. ipfilter is not used on this server, but it is present in kernel as it can be used on other servers. I have 95% CPU idle, so I think packet filters does not produce significant load on this server. Well, it was not your most serious issue, but from your profiling trace it is definitely burning cycles with every packet processed. You might try increasing BUCKET_MAX in sys/vm/uma_core.c. I don't really understand the code here, but you seem to be hitting a threshold behaviour where you are constantly running out of space in the per CPU caches. Thanks, I'll try this. This can happen if your workload is unbalanced between the CPUs and you are always allocating on one but freeing on another, but I wouldn't expect it should happen on your workload. Maybe it can also happen if your turnover is high enough. This is very unlikely, because I have 5 another video storage servers of the same hardware and software configurations and they feel good. Clearly something is different about them, though. If you can characterize exactly what that is then it will help. On the other side, all other servers were put in production before or after problematic servers and were filled with content in the other ways and therefore they could have slightly differerent load pattern. Totally I faced this bug three times: 1. The first time there was AFAIR 5.4-RELEASE on DELL 2850 with the same configuration as now. It was mp3 store and I used thttpd as HTTP server to serve mp3's. That time the problems were not so frequent and also it took too long to get back to normal operation so we had to reboot servers once a week or so. The problems began when we moved to new hardware - Dell 2850. That time we suspected amrd driver and had no time to dig in, bacause all the servers of the project were problematic. Installing Linux helped. 2. The second time it was server for static files of the very popular blog. The http server was nginx and disk contented puctures, mp3's and videos. It was Dell 1850 2x146 SCSI mirror. Linux also solved the problem. 3. The problem we see now. At first glance one can say that problem is in Dell's x850 series or amr(4), but we run this hardware on many other projects and they work well. Also Linux on them works. OK but there is no evidence in what you posted so far that amr is involved in any way. There is convincing evidence that it is the mbuf issue. And few hours ago I received feed back from Andrzej Tobola, he has the same problem on FreeBSD 7 with Promise ATA software mirror: Well, he didnt provide any evidence yet that it is the same problem, so let's not become confused by feelings :) So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: After some time of running under high load disk performance become expremely poor. At that periods 'systat -vm 1' shows something like this: What does high load mean? You need to explain the system workload more. Disks amrd0 KB/t 85.39 tps 5 MB/s 0.38 % busy 99 Apart of all, I tried to make mutex profiling and here's the results (sorted by the total number of acquisitions): Bad case: 102 223514 273977 0 14689 1651568 /usr/src/sys/vm/uma_core.c:2349 (512) 950 263099 273968 0 15004 14427 /usr/src/sys/vm/uma_core.c:2450 (512) 108 150422 175840 0 10978 22988519 /usr/src/sys/vm/uma_core.c:1888 (mbuf) Here you can see that high UMA activity happens in periods of low disk performance. But I'm not sure whether this is a root of the problem, not a consequence. The extremely high contention there does seem to say you have a mbuf starvation problem and not a disk problem. I don't know why this would be happening off-hand. Can you also provide more details about the system hardware and configuration? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Video memory as swap under FreeBSD
Vladimir Terziev wrote: Hi Hackers, i have found the following very interesting link: http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap It's a howto for Video memory utilization as a swap. Could someone point me whether the same is possible under FreeBSD ? Thanks in advance! It is not. Apart from the geek factor I doubt this would be useful as swap anyway, typically you need much more memory than a video card contains. Maybe as a small ram disk. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Benjie Chen wrote: Ivan and Kris, I will try to get a kernel trace -- it may not happen for awhile since I am not in the office and working remotely for awhile so it may not be easy to get a trace... but I will check. It looks like the problem reported by that link, and some of the links from there though... Does it really? i.e. did you compare the function names in detail and find that they match precisely, or do you just mean they are both panics of some description and I dunno what it all means? :) I ask because the linked trace does not involve a spinlock, which means it cannot be precisely the same trace. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Benjie Chen wrote: You are right, they may not be the same. From first look it seems like they are similar based on the description of the problems -- system stable, then under load related to network, get panic after different time intervals. I just assumed that kernel is typically stable enough that this kind of panic are rare (been using FBSD for 7 or 8 years now and in heavy loads as well, never had kernel panics to deal with). OK, that means it is likely it has absolutely nothing in common. I did reboot the system and set mpsafenet to 0 and I have not had a crash since then (almost a day) running the same load, so that's positive: at least it may be that that's the workaround, and I don't need Dell to send me new memory modules to try... That should only be considered a temporary workaround while you continue to obtain debugging information to solve the problem for good. e.g. support for mpsafenet=0 has already been removed from 7.0. Kris or Ivan: I was wondering if you could briefly explain what your guess the problem might be. I am curious what the cause of the problem is. E.g. it seems like a race condition, but I am curious to know more of the details... It is impossible to say until you obtain some actual details about the panic :) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Ivan Voras wrote: Kris Kennaway wrote: Does it really? i.e. did you compare the function names in detail and find that they match precisely, or do you just mean they are both panics of some description and I dunno what it all means? :) I ask because the linked trace does not involve a spinlock, which means it cannot be precisely the same trace. Isn't spinning and waiting adaptive? (AFAIK some locks spin for a short while before they wait). At least, that's why I thought they might be the same problem. Not in the sense of transmuting a sleep mutex into a spin mutex, no. sleep mutexes will spin when the lock holder is currently running, but this happens within the context of the mtx_lock_sleep function itself. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Borja Marcos wrote: On 22 Sep 2007, at 00:26, Benjie Chen wrote: FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. What number is the PR with the details? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Benjie Chen wrote: Hi FreeBSD hackers and engineers, I am experiencing a kernel panic that comes on when my new PowerEdge 1950 FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people on the list who have given me useful comments, some of which I am still following up. But I wanted to send a general cry for help to see if there are more knowledge out there about this problem. FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. I've ran exhaustively memory tests, disk tests, and network tests and cannot produce the kernel panic. I worked with Dell support to run memory test 1 DIMM at a time and cannot find any problem. With 1 DIMM at a time, I could still get the kernel panic under my work load. My work load is heavily hitting a web site running on the machine and requiring the web service to do MySQL requests. On the side, I am running a bunch of scripts that mostly read from the MySQL database but also write to it occasionally. Not memory intensive -- still have usually about 1GB free memory, but fairly disk intensive. I don't get disk errors. Anywhere from between 10 minutes to 4 or 5 hours into the test, I get the kernel panic. Again, still no disk errors. I turned off soft-update, still happens. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. There are a few other complaints about kernel panics at the same IP on the web (google 0xc066c731)... I was wondering if anyone had dealt with this before and if there are any work arounds? The IP is meaningless, it changes each time you compile your kernel. Unfortunately even knowing that it is in that symbol is nearly meaningless, because it doesn't provide enough information (only that your panic involved a spin mutex somehow). Please read the chapter on kernel debugging in the developers handbook and file a PR containing enough information for a developer to investigate the problem. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Borja Marcos wrote: On 24 Sep 2007, at 11:33, Kris Kennaway wrote: Borja Marcos wrote: I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. What number is the PR with the details? Sorry, I couldn't diagnose anything properly. When it happened the sysadmin didn't give me the panic details, and being production machines the main priority was to put them back into service as soon as possible. Would it be a good idea to file a PR with such fuzzy information? I don't think so, that's why I didn't do it. Of course I can do it if someone thinks it's worth. But unfortunately I cannot get more precise details. No it isn't. You will need to do some more work to obtain this information, otherwise your bug will probably not be fixed. debug.mpsafenet=0 is no longer an option in 7.0, so you will have to deal with this sooner or later. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Ivan Voras wrote: Benjie Chen wrote: Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. When you get a kernelbacktrace, see if it's the same as the one mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html Surely it cannot be since it involves a different function ;-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Australian cvs repository
On Thu, Aug 16, 2007 at 08:49:21AM +1000, [EMAIL PROTECTED] wrote: Robert McKenzie wrote: Has anyone noted that the Australian cvs repository seems to be so hopelessly out of sink that you cannot do a clean build using a clean cvsup. Because we are so far away it is hard to keep things sinkronized. How is that the case? Kris pgpvFAMUF7waG.pgp Description: PGP signature
Re: [patch] enhance powerd(8) to handle max temperature
On Mon, Jul 30, 2007 at 11:28:59AM +0200, Pietro Cerutti wrote: Hajimu UMEMOTO wrote: Hi, On Fri, 27 Jul 2007 16:43:29 +0200 Pietro Cerutti [EMAIL PROTECTED] said: gahr Hi list, gahr here is a patch to allow powerd(8) accept a -t tval option to set a gahr temperature limit above which performance should be decreased. gahr It's a first draft, and I identified the following problems: gahr - the CPU temperature takes some time to decrease, so powerd keeps gahr decreasing the CPU frequency until the temperature is below the limit. gahr The effect is a increase to maximum, decrease to minimum, increase to gahr maximum, decrease to minimum, which may not be desirable. gahr - the temperature is retrieved by the hw.acpi.thermal.tz0.temperature gahr sysctl MIB. Support for other methods would be desirable. gahr The patches to powerd.c and powerd.8 are here: gahr http://www.gahr.ch/FreeBSD/patches/powerd.c.diff gahr http://www.gahr.ch/FreeBSD/patches/powerd.8.diff gahr Any comment is welcome! We have a passive cooling mechanism already in our kernel. It runs according to an ACPI specification. You are right, but the passive colling mechanism could not be available on some systems where thermal is available, and I'm still waiting for answers about acpi_thermal not sending notifies. See my previous post: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021361.html What's wrong with including this feature directly in powerd? In general duplication is undesirable. You should focus on trying to solve the problems with using the ACPI method. For example, the acpi passive cooling probably uses a better algorithm than your patches, e.g. including appropriate hysteresis. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM
On Mon, Jun 18, 2007 at 05:15:30PM -0400, Martin Turgeon wrote: 2007/6/18, Jeremy Chadwick [EMAIL PROTECTED]: On Mon, Jun 18, 2007 at 01:03:44PM -0400, Martin Turgeon wrote: I just receive 2 PowerEdge servers (a 1950 and a 860) both with 4G of RAM. I installed FreeBSD 6.2 Release i386 on both of them. Unfortunately, only 3,5G is recognized on the 860 and 3,3G on the 1950. dmesg on 860: real memory = 3757834240 (3583 MB) avail memory = 3678318592 (3507 MB) I am facing a difficult decision. Should I use i386 with PAE enabled in the kernel (I read a lot of warnings using it) or should I go with AMD64? Which branch should I follow? Based on what I've read from some of the porters and miscellaneous others, generally-speaking there's too many issues with amd64 (in the sense of 32-bit vs. 64-bit compatibility -- not the fault of the kernel or otherwise) to consider it worth switching to. I personally don't run 64-bit OSes because most developers still use 32-bit machines and don't have a way to develop/test in 64-bit environments. That said, I'd recommend you stick with i386 + PAE, simply for guaranteed application compatibility. My setup is fairly standard (as I described), should I expect problem with 64 bit version of these programs? No. I'd go with amd64 personally. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM
On Mon, Jun 18, 2007 at 03:10:22PM -0700, Jeremy Chadwick wrote: On Mon, Jun 18, 2007 at 05:15:30PM -0400, Martin Turgeon wrote: My setup is fairly standard (as I described), should I expect problem with 64 bit version of these programs? Like I said, I don't run 64-bit OSes because I prefer compatibility. Believe me, the instant you run into some quirky problem with either the kernel or any of its subsystems, or a third-party program (from ports or otherwise), the first thing you'll be told is it works for me on i386, have you tried i386? I think this assertion is false. amd64 is pretty well supported and run by an increasing number of users and developers. Kris pgpmbJard9nZx.pgp Description: PGP signature
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 04:15:29PM -0700, Jeff Anton wrote: I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. Well, it didn't. I'm sure hacker's isn't the right list for this Correct. but it is so amazing that I don't know what the right list would be Ports problems go to the ports list. Problems with a particular port (e.g. portupgrade) go to that list and/or the port's maintainer. Deinstall xorg-manpages-6.9.0 ? [no] yes --- Deinstalling 'xorg-manpages-6.9.0' [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 70 packages found (-1 +0) (...) done] -- Done. Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): . Abort. 62.580u 41.058s 2:08.82 80.4% 157+2488k 1300+1603io 12pf+0w You need to go through the xorg 7.2 upgrade. Most of what you chose to do was actually damaging your port installations, e.g. --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Whee, you've deleted metadata that was required for correctness of future upgrades. Deleted. Stale dependency: Xaw3d-1.5E_1 - libXdamage-1.1.1 (x11/libXdamage): libXft-2.1.7_1 (score:25%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - renderproto-0.9.2 (x11/renderproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - compositeproto-0.3.1 (x11/compositeproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n This is the only part that doesn't make sense. Are you sure you didn't do e.g. 'y^Hn' where that was not interpreted by the terminal as a backspace but as a string beginning with 'y'? It's the only way I can think that this would trigger the 'yes' branch. Anyway, it wasn't doing 'portupgrade -a' but trying to bring your system up to a consistent state. Really what you probably should have done was either leave your system alone (i.e. not answered 'yes' to requests to modify things), or go through the documented x.org 7.2 upgrade procedure to perform the upgrade correctly and completely. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 07:59:14PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Jeff Anton [EMAIL PROTECTED] typed: I'm very surprised and upset that running pkgdb -F has started a whole upgrade of my stable machine. I'm sure hacker's isn't the right list for this but it is so amazing that I don't know what the right list would be and I think just calling attention to some very bizarre behavior is maybe the best thing. This machine should only have X11 clients... Anyhow output below... Hi Jeff, Long time no see. The only wierd thing I see is right here: Stale dependency: Xaw3d-1.5E_1 - libXv-1.0.3,1 (x11/libXv): libXft-2.1.7_1 (score:22%) ? ([y]es/[n]o/[a]ll) [no] Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n --- Installing 'libXv-1.0.3,1' from a port (x11/libXv) --- Building '/usr/ports/x11/libXv' Where it starts installing the port even though you told it not to. That's a pkgdb issue, and the right person to talk to is the portupgrade maintainer, [EMAIL PROTECTED] For the rest of it - you've apperently got x.org 6.9 installed on the system and x.org 7.0 in the ports tree. So once it starts installing ports, it's pretty much going to install the entire xorg ports set. Since they install in different prefixes (7.0 moved to /usr/local), that will actually work. Unfortunately it will not work and will actually lead to package database corruption due to a portupgrade bug. That's why the more extensive upgrade process in UPDATING is necessary. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgdb -F calling portupgrade -a
On Sun, Jun 10, 2007 at 08:15:33PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: --- Checking the package registry database Stale dependency: Xaw3d-1.5E_1 - xf86dgaproto-2.0.2 (x11/xf86dgaproto): Install stale dependency? ([y]es/[n]o/[a]ll) [yes] n ^ New dependency? (? to help): Delete this? ([y]es/[n]o/[a]ll) [yes] Whee, you've deleted metadata that was required for correctness of future upgrades. Just out of curiosity, what should he have done? Yes, the data was required for the correctness of future upgrades, but the data was broken in ways that the automated tools couldn't deal with. Installing the stale dependency would lead to incorrectly trying to install the new x.org 7 ports. There's no right-looking new dependency to use, or pkgdb would have suggested it. Leaving the dependency in place wouldn't solve the problem that pkgdb was run to fix in the first place. So what's the right alternative? I guess deleting it is probably the least bad alternative, followed by upgrading to xorg 7.2, followed by a pkgdb -L to repair the damage. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
On Tue, May 29, 2007 at 12:07:44AM -0700, Doug Barton wrote:
Alex Dupre wrote:
Doug Barton wrote:
(Over 2GBs of RAM + Swap being used). It does this consistently when it
tries to compile xf86PciScan.c (hope thats the right file).
May not be the answer you want to hear, but I built all the xorg stuff
multiple times on -current systems both pre and post the gcc + symver
+ version bump eras, and didn't have the problems you're seeing.
It's the well-known problem of new gcc 4.2 optimizations (bug). Simply
compile with -O0 instead of -O2.
Not disputing your answer, but I'm curious. Why would it cause
problems on some systems but not others? I haven't done anything with
my cflags ...
It wants to use ${BIGNUM} amount of memory to optimize a huge C file,
so that might be fatal (or just terminally irritating) on smaller
systems.
Kris
pgpYA6AWk5tYl.pgp
Description: PGP signature
Re: DPS Initial Ideas
On Mon, May 14, 2007 at 04:52:47PM -0500, Rick C. Petty wrote: On Mon, May 14, 2007 at 10:25:12AM +0200, 'Michel Talon' wrote: niobe% sqlite3 index.db sqlite CREATE TABLE index6 ( pkgname varchar(1), path varchar(1), prefix varchar(1), comment varchar(1), descr varchar(1), maintainer varchar(1), categories varchar(1), build_deps varchar(1), run_deps varchar(1), website varchar(1), extract_deps varchar(1), patch_deps varchar(1), fetch_deps varchar(1)); sqlite .import INDEX-6 index6 ... completes in less than 2 seconds sqlite select * from index6 where path = /usr/ports/accessibility/atk; atk-1.12.4|/usr/ports/accessibility/atk|/usr/local|A GNOME accessibility toolkit (ATK)|/usr/ports/accessibility/atk/pkg-descr|[EMAIL PROTECTED]|accessibility devel|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 libtool-1.5.22_3 perl-5.8.8 pkg-config-0.21|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 perl-5.8.8 pkg-config-0.21|http://developer.gnome.org/projects/gap/||libtool-1.5.22_3| What this shows me is that sqlite doesn't follow SQL92 standards. According to the section 6.1 of the standard[1]: Syntax rule #1 states VARCHAR is equivalent to CHARACTER VARYING. Syntax rule #9b states If VARYING is specified in character string type, then the length in characters of the character string is variable, with a minimum length of 0 and a maximum length of the value of length. So your example should have failed to work correctly. You should have used something more appropriate, like VARCHAR(255) instead of VARCHAR(1). Some of the fields can (and do) have unbounded length. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
