From krassi at bulinfo.net Mon Nov 3 03:15:27 2008 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Nov 3 03:16:09 2008 Subject: 1. thread switching time? (Krassimir Slavchev) In-Reply-To: <490AB750.9040505@elischer.org> References: <000001c93b0c$6195e6b0$2f096f0a@china.huawei.com> <490AB477.2080001@bulinfo.net> <490AB750.9040505@elischer.org> Message-ID: <490EDD49.5070902@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: > Krassimir Slavchev wrote: > >> >> Also, I am able to set HZ=100000 but the thread switching time is still >> ~1ms. > > You must be talking about the time that a thread can run before it is > pushed out by other threads? I know I've seem many x 10,000 context > switches in some cases, i.e. look at very high interrupt rates > etc. so I guess I'm not sure what you are measuring.. > > at one time the scheduling quantum was independent of Hz. > I am not sure how true that is now.. > The scheduling quantum is independent of Hz for Hz > 1000. usr/src/sys/kern_tc.c: ... if (hz > 1000) tc_tick = (hz + 500) / 1000; else tc_tick = 1; ... I am not sure whether setting Hz > 1000 impact on performance or not, e.g using polling(4). Removing this limitation and setting kern.hz=10000 give 100usec quantum. Thanks for the point. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJDt1JxJBWvpalMpkRAnWCAJ9z5Z7JYDC/3AdsJe+Cn7+dg6y3HwCdHPZA 6sK5dec43n41/QcbiluJoeA= =8u2E -----END PGP SIGNATURE----- From xiazhongqi at huawei.com Mon Nov 3 19:05:34 2008 From: xiazhongqi at huawei.com (Sam Xia) Date: Mon Nov 3 19:05:41 2008 Subject: freebsd-performance Digest, Vol 69, Issue 2 In-Reply-To: <20081103120020.5188D106579C@hub.freebsd.org> Message-ID: <000001c93e2a$23db4150$2f096f0a@china.huawei.com> if you modify file subr_param.c as follows: void init_param1(void) { hz = HZ; ===> hz=HZ*4 . . . } you will get what you want. i have tested.it works well. Best Regards, Sam Xia > -----Original Message----- > From: owner-freebsd-performance@freebsd.org > [mailto:owner-freebsd-performance@freebsd.org] On Behalf Of > freebsd-performance-request@freebsd.org > Sent: Monday, November 03, 2008 8:00 PM > To: freebsd-performance@freebsd.org > Subject: freebsd-performance Digest, Vol 69, Issue 2 > > Send freebsd-performance mailing list submissions to > freebsd-performance@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > or, via email, send a message with subject or body 'help' to > freebsd-performance-request@freebsd.org > > You can reach the person managing the list at > freebsd-performance-owner@freebsd.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of freebsd-performance digest..." > > > Today's Topics: > > 1. Re: 1. thread switching time? (Krassimir Slavchev) > (Krassimir Slavchev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 03 Nov 2008 13:15:21 +0200 > From: Krassimir Slavchev > Subject: Re: 1. thread switching time? (Krassimir Slavchev) > To: Julian Elischer > Cc: freebsd-performance@freebsd.org, Sam Xia > Message-ID: <490EDD49.5070902@bulinfo.net> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julian Elischer wrote: > > Krassimir Slavchev wrote: > > > >> > >> Also, I am able to set HZ=100000 but the thread switching time is > >> still ~1ms. > > > > You must be talking about the time that a thread can run > before it is > > pushed out by other threads? I know I've seem many x > 10,000 context > > switches in some cases, i.e. look at very high interrupt > rates etc. so > > I guess I'm not sure what you are measuring.. > > > > at one time the scheduling quantum was independent of Hz. > > I am not sure how true that is now.. > > > > The scheduling quantum is independent of Hz for Hz > 1000. > > usr/src/sys/kern_tc.c: > ... > if (hz > 1000) > tc_tick = (hz + 500) / 1000; > else > tc_tick = 1; > ... > > I am not sure whether setting Hz > 1000 impact on performance > or not, e.g using polling(4). > Removing this limitation and setting kern.hz=10000 give > 100usec quantum. > > Thanks for the point. > > Best Regards > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFJDt1JxJBWvpalMpkRAnWCAJ9z5Z7JYDC/3AdsJe+Cn7+dg6y3HwCdHPZA > 6sK5dec43n41/QcbiluJoeA= > =8u2E > -----END PGP SIGNATURE----- > > > ------------------------------ > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > > End of freebsd-performance Digest, Vol 69, Issue 2 > ************************************************** > From lolo at troll.free.org Fri Nov 21 09:35:01 2008 From: lolo at troll.free.org (Laurent Frigault) Date: Fri Nov 21 09:35:29 2008 Subject: hwpmc / high resolution profiling kernel Message-ID: <20081121170643.GA41695@troll.free.org> Hi, I try to use hwpmc to find a net/lagg performance problem on a DELL poweredge 2950 with dual E5440 (AMD64 7.1-PRERELEASE form yesterday) , but it seems that those processor are not recognized by hwpmc . Is there a known fix / work arround ? I also try to build an high resolution profiling kernel (config -p -p), but it freeze at boot time. A standard profiling kernel (config -p) boots fine. Any advice ? Regards, -- Laurent Frigault | Free.org From attilio at freebsd.org Sun Nov 23 05:32:32 2008 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 23 05:32:38 2008 Subject: [PATCH] pmcannotate tool Message-ID: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> pmcannotate is a tool that prints out sources of a tool (in C or assembly) with inlined profiling informations retrieved by a prior pmcstat analysis. If compared with things like callgraph generation, it prints out profiling on a per-instance basis and this can be useful to find, for example, badly handled caches, too high latency instructions, etc. The tool usage is pretty simple: pmcannotate [-a] [-h] [-k path] [-l level] samples.out binaryobj where samples.out is a pmcstat raw output and binaryobj is the binary object that has been profiled and is accessible for (ELF) symbols retrieving. The options are better described in manpages but briefly: - a: performs analysis on the assembly rather than the C source - h: usage and informations - k: specify a path for the kernel in order to locate correct objects for it - l: specify a lower boundary (in total percentage time) after which functions will be displayed nomore. A typical usage of pmcannotate can be some way of kernel annotation. For example, you can follow the steps below: 1) Generate a pmc raw output of system samples: # pmcstat -S ipm-unhalted-core-cycles -O samples.out 2) Copy the samples in the kernel building dir and cd there # cp samples.out /usr/src/sys/i386/compile/GENERIC/ ; cd /usr/src/sys/i386/compile/GENERIC/ 3) Run pmcannotate # pmcannotate -k . samples.out kernel.debug > kernel.ann In the example above please note that kernel.debug has to be used in order to produce a C annotated source. This happens because in order to get the binary sources we rely on the "objdump -S" command which wants binary compiled with debugging options. If not debugging options are present assembly analynsis is still possible, but no C-backed one will be available. objdump is not the only one tool on which pmcannotare rely. Infact, in order to have it working, pmcstat needs to be present too because we need to retrieve, from the pmcstat raw output, informations about the sampled PCs (in particular the name of the function they live within, its start and ending addresses). As long as currently pmcstat doesn't return those informations, a new option has been added to the tool (-m) which can extract (from a raw pmcstat output) all pc sampled, name of the functions and symbol bundaries they live within. Also please note that pmcannotate suffers of 2 limitations. Firstly, relying on objdump to dump the C source, with heavy optimization levels and lots of inlines the code gets difficult to read. Secondly, in particular on x86 but I guess it is not the only one case, the sample is always attributed to the instruction directly following the one that was interrupted. So in a C source view some samples may be attributed to the line below the one you're interested in. It's also important to keep in mind that if a line is a jump target or the start of a function the sample really belongs elsewhere. The patch can be found here: http://www.freebsd.org/~attilio/pmcannotate.diff/ where pmcannotate/ dir contains the code and needs to go under /usr/src/usr.sbin/ and the patch has diffs against pmcstat and Makefile. This work has been developed on the behalf of Nokia with important feedbacks and directions from Jeff Roberson. Testing and feedbacks (before it hits the tree) are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From joseph.koshy at gmail.com Sun Nov 23 06:08:10 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Sun Nov 23 08:01:32 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> Message-ID: <84dead720811230544l625a565w158ccc1833b73799@mail.gmail.com> > pmcannotate is a tool that prints out sources of a tool (in C or > assembly) with inlined profiling informations retrieved by a prior > pmcstat analysis. [snip] > This work has been developed on the behalf of Nokia with important > feedbacks and directions from Jeff Roberson. Are you "rookie" on IRC, who used to catch me with tons of questions whenever I logged on? > Testing and feedbacks (before it hits the tree) are welcome. The pmcstat changes seem fine. Koshy From Alexander at Leidinger.net Sun Nov 23 12:11:41 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Nov 23 12:11:48 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> Message-ID: <20081123205603.17752y578er4bcqo@webmail.leidinger.net> Quoting Attilio Rao (from Sun, 23 Nov 2008 14:02:22 +0100): > pmcannotate is a tool that prints out sources of a tool (in C or > assembly) with inlined profiling informations retrieved by a prior > pmcstat analysis. > If compared with things like callgraph generation, it prints out > profiling on a per-instance basis and this can be useful to find, for > example, badly handled caches, too high latency instructions, etc. Can this also be used to do some code coverage analysis? What I'm interested in is to enable something, run some tests in userland, disable this something, and then run a tool which tells me which parts of specific functions where run or not. At first I hoped I can use dtrace for this... I had a dtrace training and seen the userland probes in action, where you can trace every ASM instruction, but unfortunately you can not do this with kernel probes. I tried with fbt and syscall on a Solaris 10 machine. I haven't tested with FreeBSD-dtrace yet, but I doubt it is more advanced in this regard than the Solaris dtrace. So I'm still searching. Bye, Alexander. -- We should keep the Panama Canal. After all, we stole it fair and square. -- S. I. Hayakawa http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From raykinsella78 at gmail.com Sun Nov 23 12:26:30 2008 From: raykinsella78 at gmail.com (Ray Kinsella) Date: Sun Nov 23 12:26:37 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> Message-ID: <584ec6bb0811231226x7d1b53ccgc5e28bfc297009a2@mail.gmail.com> I know I am going to really show my FreeBSD ignorance here, but this is a patch of FreeBSD 8.0 Current isn't it ? Thanks Ray Kinsella On Sun, Nov 23, 2008 at 1:02 PM, Attilio Rao wrote: > pmcannotate is a tool that prints out sources of a tool (in C or > assembly) with inlined profiling informations retrieved by a prior > pmcstat analysis. > If compared with things like callgraph generation, it prints out > profiling on a per-instance basis and this can be useful to find, for > example, badly handled caches, too high latency instructions, etc. > > The tool usage is pretty simple: > pmcannotate [-a] [-h] [-k path] [-l level] samples.out binaryobj > > where samples.out is a pmcstat raw output and binaryobj is the binary > object that has been profiled and is accessible for (ELF) symbols > retrieving. > The options are better described in manpages but briefly: > - a: performs analysis on the assembly rather than the C source > - h: usage and informations > - k: specify a path for the kernel in order to locate correct objects for > it > - l: specify a lower boundary (in total percentage time) after which > functions will be displayed nomore. > > A typical usage of pmcannotate can be some way of kernel annotation. > For example, you can follow the steps below: > 1) Generate a pmc raw output of system samples: > # pmcstat -S ipm-unhalted-core-cycles -O samples.out > 2) Copy the samples in the kernel building dir and cd there > # cp samples.out /usr/src/sys/i386/compile/GENERIC/ ; cd > /usr/src/sys/i386/compile/GENERIC/ > 3) Run pmcannotate > # pmcannotate -k . samples.out kernel.debug > kernel.ann > > In the example above please note that kernel.debug has to be used in > order to produce a C annotated source. This happens because in order > to get the binary sources we rely on the "objdump -S" command which > wants binary compiled with debugging options. > If not debugging options are present assembly analynsis is still > possible, but no C-backed one will be available. > objdump is not the only one tool on which pmcannotare rely. Infact, in > order to have it working, pmcstat needs to be present too because we > need to retrieve, from the pmcstat raw output, informations about the > sampled PCs (in particular the name of the function they live within, > its start and ending addresses). As long as currently pmcstat doesn't > return those informations, a new option has been added to the tool > (-m) which can extract (from a raw pmcstat output) all pc sampled, > name of the functions and symbol bundaries they live within. > > Also please note that pmcannotate suffers of 2 limitations. > Firstly, relying on objdump to dump the C source, with heavy > optimization levels and lots of inlines the code gets difficult to > read. Secondly, in particular on x86 but I guess it is not the only > one case, the sample is always attributed to the instruction directly > following the one that was interrupted. So in a C source view some > samples may be attributed to the line below the one you're interested > in. It's also important to keep in mind that if a line is a jump > target or the start of a function the sample really belongs elsewhere. > > The patch can be found here: > http://www.freebsd.org/~attilio/pmcannotate.diff/ > > where pmcannotate/ dir contains the code and needs to go under > /usr/src/usr.sbin/ and the patch has diffs against pmcstat and > Makefile. > > This work has been developed on the behalf of Nokia with important > feedbacks and directions from Jeff Roberson. > > Testing and feedbacks (before it hits the tree) are welcome. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > From attilio at freebsd.org Sun Nov 23 15:46:32 2008 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 23 15:46:37 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <20081123205603.17752y578er4bcqo@webmail.leidinger.net> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <20081123205603.17752y578er4bcqo@webmail.leidinger.net> Message-ID: <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> 2008/11/23, Alexander Leidinger : > Quoting Attilio Rao (from Sun, 23 Nov 2008 14:02:22 > +0100): > > > > pmcannotate is a tool that prints out sources of a tool (in C or > > assembly) with inlined profiling informations retrieved by a prior > > pmcstat analysis. > > If compared with things like callgraph generation, it prints out > > profiling on a per-instance basis and this can be useful to find, for > > example, badly handled caches, too high latency instructions, etc. > > > > Can this also be used to do some code coverage analysis? What I'm > interested in is to enable something, run some tests in userland, disable > this something, and then run a tool which tells me which parts of specific > functions where run or not. Yes, this is exactly what it does. You can see traces for any sampled PC and so get a profiling anslysis on a per-instance basis. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sun Nov 23 15:47:01 2008 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 23 15:47:12 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <584ec6bb0811231226x7d1b53ccgc5e28bfc297009a2@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <584ec6bb0811231226x7d1b53ccgc5e28bfc297009a2@mail.gmail.com> Message-ID: <3bbf2fe10811231547w651dea65h211b82ae4dcef005@mail.gmail.com> 2008/11/23, Ray Kinsella : > I know I am going to really show my FreeBSD ignorance here, but this is a > patch of FreeBSD 8.0 Current isn't it ? Yes, it is for 8.0. Is it giving you problems? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From jroberson at jroberson.net Sun Nov 23 16:21:00 2008 From: jroberson at jroberson.net (Jeff Roberson) Date: Sun Nov 23 16:21:07 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <20081123205603.17752y578er4bcqo@webmail.leidinger.net> <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> Message-ID: <20081123135009.I971@desktop> On Mon, 24 Nov 2008, Attilio Rao wrote: > 2008/11/23, Alexander Leidinger : >> Quoting Attilio Rao (from Sun, 23 Nov 2008 14:02:22 >> +0100): >> >> >>> pmcannotate is a tool that prints out sources of a tool (in C or >>> assembly) with inlined profiling informations retrieved by a prior >>> pmcstat analysis. >>> If compared with things like callgraph generation, it prints out >>> profiling on a per-instance basis and this can be useful to find, for >>> example, badly handled caches, too high latency instructions, etc. >>> >> >> Can this also be used to do some code coverage analysis? What I'm >> interested in is to enable something, run some tests in userland, disable >> this something, and then run a tool which tells me which parts of specific >> functions where run or not. > > Yes, this is exactly what it does. > You can see traces for any sampled PC and so get a profiling anslysis > on a per-instance basis. I would add that it is only sampled so you don't see every instruction executed. You can use gcov for that however. That's precisely what it's for. Thanks, Jeff > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From Alexander at Leidinger.net Sun Nov 23 23:39:30 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Nov 23 23:39:36 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <20081123205603.17752y578er4bcqo@webmail.leidinger.net> <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> Message-ID: <20081124083920.16126d6j9o1q9mw4@webmail.leidinger.net> Quoting Attilio Rao (from Mon, 24 Nov 2008 00:46:29 +0100): > 2008/11/23, Alexander Leidinger : >> Quoting Attilio Rao (from Sun, 23 Nov 2008 14:02:22 >> +0100): >> >> >> > pmcannotate is a tool that prints out sources of a tool (in C or >> > assembly) with inlined profiling informations retrieved by a prior >> > pmcstat analysis. >> > If compared with things like callgraph generation, it prints out >> > profiling on a per-instance basis and this can be useful to find, for >> > example, badly handled caches, too high latency instructions, etc. >> > >> >> Can this also be used to do some code coverage analysis? What I'm >> interested in is to enable something, run some tests in userland, disable >> this something, and then run a tool which tells me which parts of specific >> functions where run or not. > > Yes, this is exactly what it does. > You can see traces for any sampled PC and so get a profiling anslysis > on a per-instance basis. Cool. Would be great if you could provide some example in the man page or as a script which shows how to do this for kernel code. This would immediately show us how good our regression tests are for their specific areas of test. Bye, Alexander. -- In a family recipe you just discovered in an old book, the most vital measurement will be illegible. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Sun Nov 23 23:40:27 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Nov 23 23:40:38 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <20081123135009.I971@desktop> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <20081123205603.17752y578er4bcqo@webmail.leidinger.net> <3bbf2fe10811231546r44bd2aafqa3d714a4955f52ad@mail.gmail.com> <20081123135009.I971@desktop> Message-ID: <20081124084015.84153bmq6411va68@webmail.leidinger.net> Quoting Jeff Roberson (from Sun, 23 Nov 2008 13:50:35 -1000 (HST)): > > On Mon, 24 Nov 2008, Attilio Rao wrote: > >> 2008/11/23, Alexander Leidinger : >>> Quoting Attilio Rao (from Sun, 23 Nov 2008 14:02:22 >>> +0100): >>> >>> >>>> pmcannotate is a tool that prints out sources of a tool (in C or >>>> assembly) with inlined profiling informations retrieved by a prior >>>> pmcstat analysis. >>>> If compared with things like callgraph generation, it prints out >>>> profiling on a per-instance basis and this can be useful to find, for >>>> example, badly handled caches, too high latency instructions, etc. >>>> >>> >>> Can this also be used to do some code coverage analysis? What I'm >>> interested in is to enable something, run some tests in userland, disable >>> this something, and then run a tool which tells me which parts of specific >>> functions where run or not. >> >> Yes, this is exactly what it does. >> You can see traces for any sampled PC and so get a profiling anslysis >> on a per-instance basis. > > I would add that it is only sampled so you don't see every > instruction executed. You can use gcov for that however. That's > precisely what it's for. How to use gcov for the kernel? Bye, Alexander. -- If only you knew she loved you, you could face the uncertainty of whether you love her. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From raykinsella78 at gmail.com Mon Nov 24 00:48:10 2008 From: raykinsella78 at gmail.com (Ray Kinsella) Date: Mon Nov 24 00:48:15 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811231547w651dea65h211b82ae4dcef005@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> <584ec6bb0811231226x7d1b53ccgc5e28bfc297009a2@mail.gmail.com> <3bbf2fe10811231547w651dea65h211b82ae4dcef005@mail.gmail.com> Message-ID: <584ec6bb0811240048x2304a759j2ac6fdea83a47773@mail.gmail.com> No, not at all. I am using 6.2 and 7.0 at the moment, I will build another disk with FreeBSD 8.0-CURRENT. Thanks Ray Kinsella On Sun, Nov 23, 2008 at 11:47 PM, Attilio Rao wrote: > 2008/11/23, Ray Kinsella : > > I know I am going to really show my FreeBSD ignorance here, but this is a > > patch of FreeBSD 8.0 Current isn't it ? > > Yes, it is for 8.0. > Is it giving you problems? > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > From vadim_nuclight at mail.ru Mon Nov 24 03:29:23 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Mon Nov 24 03:29:29 2008 Subject: hwpmc granularity and 6.4 network performance Message-ID: Hi! I've recently perfromed upgrade of busy production router from 6.2 to 6.4-PRE. I have added two lines to my kernel config and did usual make buildkernel: device hwpmc # Driver (also a loadable module) options HWPMC_HOOKS # Other necessary kernel hooks After rebooting with new world and kernel, I've noticed that CPU load has slightly increased (not measured, it is different every second anyway, as users do not genereate steady traffic), and in top -S 'swi1: net' became often in state *Giant, but it not used to do so on 6.2, while kernel config did not changed much, and device polling is still used. What could happen to this? Another question, I've read "Sixty second HWPMC howto" and tried to find out what exactly eats my CPU. BTW, that instruction did not apply exactly on my machine, this is what I did: # cd /tmp # pmcstat -S instructions -O /tmp/sample.out # pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g # gprof /boot/kernel/kernel p4-instr-retired/kernel.gmon > kernel.gmon.result Now in file kernel.gmon.result I see the following: granularity: each sample hit covers 4 byte(s) for 0.00% of 692213.00 seconds called/total parents index %time self descendents called+self name index called/total children [1] 31.7 219129.00 0.00 ipfw_chk [1] ----------------------------------------------- [...] Why does it show 0.00 in this column ? On next listing, flat profile, I see more readable listing, but columns are empty again: granularity: each sample hit covers 4 byte(s) for 0.00% of 692213.00 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 31.7 219129.00 219129.00 ipfw_chk [1] 10.4 291179.00 72050.00 bcmp [2] 6.1 333726.00 42547.00 rn_match [3] 2.7 352177.00 18451.00 generic_bzero [4] 2.4 368960.00 16783.00 strncmp [5] OK, I can conclude from this that I should optimize my ipfw ruleset, but that's all. I know from sources that ipfw_chk() is a big function with a bunch of 'case's in a large 'switch'. I want to know which parts of that switch are executed more often. It says in listing that granularity is 4 bytes, I assume that it has a sample for each of 4-byte chunks of binary code, so that it must have such information. My kernel is compiled with: makeoptions DEBUG=-g so kgdb does know where are instructions for each line of source code. How can I obtain this info from profiling? It also would be useful to know which places do calls to that bcmp() and rn_match(). -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From killing at multiplay.co.uk Mon Nov 24 12:47:55 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Mon Nov 24 12:48:01 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance Message-ID: http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 Was interesting until I saw this:- "However, it's important to reiterate that all three operating systems were left in their stock configurations and that no additional tweaking had occurred." I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so these results are useless and someone should contact the article writers to correct this. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From mike at sentex.net Mon Nov 24 13:07:23 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Nov 24 13:07:29 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: <200811242107.mAOL7JB9058269@lava.sentex.ca> At 03:28 PM 11/24/2008, Steven Hartland wrote: >http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > >Was interesting until I saw this:- > >"However, it's important to reiterate that all three operating >systems were left in their stock configurations and that no >additional tweaking had occurred." They all seem to be fairly close in the majority of tests. In the conclusion they write, "In our LAME MP3 encoding test, Ubuntu 8.10 was the fastest followed by FreeBSD 7.1".... One needs to consider, the difference was 2%... Thats hardly anything to get excited about, especially if that difference can be accounted for by how much priority the scheduler gives to a userland app vs what the system is doing etc.... Also, it would have been interesting to see more multithreaded work loads. A lot of the apps they tested seemed to be single threaded, doing one job. ---Mike From thompsa at FreeBSD.org Mon Nov 24 13:25:07 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Nov 24 15:50:12 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: <20081124205905.GA18565@citylink.fud.org.nz> On Mon, Nov 24, 2008 at 08:28:11PM -0000, Steven Hartland wrote: > http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > > Was interesting until I saw this:- > > "However, it's important to reiterate that all three operating systems were > left in their stock configurations and that no additional tweaking had > occurred." > > I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so these results are useless > and someone should contact the article writers to correct this. The stable branches do not have any debugging turned on, only head. This would have been true if they tested a point-zero release like 7.0 BETA 2. Andrew From ssanders at softhammer.net Mon Nov 24 15:52:36 2008 From: ssanders at softhammer.net (Stephen Sanders) Date: Mon Nov 24 15:52:44 2008 Subject: boot loader bug??? Message-ID: <492B3E3E.1000001@softhammer.net> This may be a bad list to post to for this problem but I'm having an issue where in it appears that the boot loader fails and then overwrites the MBR with 0. The system boots to : F1 - Linux F3 - FreeBSD F5 - Drive 1" Default: But then fails on "boot error". Rebooting will not even make it to the prompt above and if one checks the MBR (via a PXE boot), it has been set to 512 bytes of 0. Sound familiar? Thanks From phil.brennan at gmail.com Mon Nov 24 16:12:00 2008 From: phil.brennan at gmail.com (Phil Brennan) Date: Mon Nov 24 16:12:07 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: Sorry thats one of the worst pieces of "journalism" I've ever encountered. Benchmarks useless ( single threaded ), no useful analysis, not even any speculation ( informed or otherwise ). On Mon, Nov 24, 2008 at 8:28 PM, Steven Hartland wrote: > http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > > Was interesting until I saw this:- > > "However, it's important to reiterate that all three operating systems were > left in their stock configurations and that no additional tweaking had > occurred." > > I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so these > results are useless > and someone should contact the article writers to correct this. > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From kmacy at freebsd.org Mon Nov 24 17:14:06 2008 From: kmacy at freebsd.org (Kip Macy) Date: Mon Nov 24 18:25:38 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: <3c1674c90811241647l39559628tb4f61d9e3d1c0272@mail.gmail.com> On Mon, Nov 24, 2008 at 11:43 PM, Phil Brennan wrote: > Sorry thats one of the worst pieces of "journalism" I've ever > encountered. Benchmarks useless ( single threaded ), no useful > analysis, not even any speculation ( informed or otherwise ). It is representative. This stands out in your mind because you are familiar with the subject matter. > On Mon, Nov 24, 2008 at 8:28 PM, Steven Hartland > wrote: >> http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 >> >> Was interesting until I saw this:- >> >> "However, it's important to reiterate that all three operating systems were >> left in their stock configurations and that no additional tweaking had >> occurred." >> >> I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so these >> results are useless >> and someone should contact the article writers to correct this. >> >> Regards >> Steve >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. and the >> person or entity to whom it is addressed. In the event of misdirection, the >> recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> _______________________________________________ >> freebsd-performance@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to >> "freebsd-performance-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From liudasb at centras.lt Tue Nov 25 02:18:35 2008 From: liudasb at centras.lt (=?windows-1257?B?TGl1ZGFzIEJha/B5cw==?=) Date: Tue Nov 25 02:18:42 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance Message-ID: <20081125095359.19E70100A6C4@mascareta.delfi.lt> Hello, I did some calculations to take into account not only best result, but how much it is better. I used following formulas: If more is better then result/max(ubuntu, opensolaris, freebsd) If less is better then min(ubuntu, opensolaris, freebsd)/ result Results in phoronix article Ubuntu OpenSolaris FreeBSD LAME Encoding 43,3 53,51 45,87 7-Zip Compression 10612 9655,99 9323,66 Timed Gzip Compression 111,08 116,54 122,32 GnuPG 43,49 62,39 44,72 Tandem XML 30,89 54,52 29,01 Bork File Encrypter 78,4 55,31 79,36 Java SciMark FFT 455,53 480,93 447,24 Java SciMark matrix mul. 549,16 438,25 543,02 Java SciMark SOR 742,77 734 731,22 Java SciMark Montecarlo 162,11 167,89 160,53 Sunflow rendering 6,24 6,57 5,62 Bonnie++ seq 34861 61387 56124 Bonnie++ rand read 50511 60626 56255 Bonnie++ rand del 209,3 362,4 145,4 BYTE dhrystone 8604934,5 7486935,6 12122380,5 BYTE register 553949 555089,5 547974,3 BYTE fp 1284795 933096,5 1271991,7 Results after calculations Ubuntu OpenSolaris FreeBSD 1 0,81 0,94 1 0,91 0,88 1 0,95 0,91 1 0,7 0,97 0,94 0,53 1 0,71 1 0,7 0,95 1 0,93 1 0,8 0,99 1 0,99 0,98 0,97 1 0,96 0,9 0,86 1 0,57 1 0,91 0,83 1 0,93 0,58 1 0,4 0,71 0,62 1 1 1 0,99 1 0,73 0,99 SUM 15,14 14,89 15,48 AVERAGE 0,89 0,88 0,91 I hope results are readable -- Liudas >At 03:28 PM 11/24/2008, Steven Hartland wrote: >>http://www.phoronix.com/scan.php? page=article&item=os_threeway_2008&num=1 >> >>Was interesting until I saw this:- >> >>"However, it's important to reiterate that all three operating >>systems were left in their stock configurations and that no >>additional tweaking had occurred." > >They all seem to be fairly close in the majority of tests. > >In the conclusion they write, "In our LAME MP3 encoding test, Ubuntu >8.10 was the fastest followed by FreeBSD 7.1".... One needs to >consider, the difference was 2%... Thats hardly anything to get >excited about, especially if that difference can be accounted for by >how much priority the scheduler gives to a userland app vs what the >system is doing etc.... > >Also, it would have been interesting to see more multithreaded work >loads. A lot of the apps they tested seemed to be single threaded, >doing one job. > > ---Mike > >_______________________________________________ >freebsd-performance@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-performance >To unsubscribe, send any mail to "freebsd-performance- unsubscribe@freebsd.org" > > From ivoras at freebsd.org Tue Nov 25 03:08:37 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 25 03:08:44 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: Steven Hartland wrote: > http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > > Was interesting until I saw this:- > The results seem well within expectations, for the sort of benchmarks they did: there is little difference between the systems. Depending on the details of how they did the benchmarks and how they processed the results (if at all), the results can even be within the margin of error (i.e. useless for mutual comparison except to show the systems are all very similar). The benchmarks they did are mostly focused on number crunching and do not even touch the area of system scalability to multiple CPUs, which could have been easily done but they chose not to. Number crunching is a bad choice for system scalability measure because down to the metal, all systems use similar compilers and there's nothing the OS can do to improve (or actually hinder, in the common case) CPU's execution of math code. For example, they could have included the "shells concurrent" benchmark from unixbench, started multiple bonnie++'s in parallel, and included a few system benchmarks like lighttpd+siege, parallel gzip (pigz) and blogbench. > "However, it's important to reiterate that all three operating systems > were left in their stock configurations and that no additional tweaking > had occurred." > > I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so > these results are useless > and someone should contact the article writers to correct this. There is no debugging in -STABLE. WYSIWYG :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20081125/ac0b6223/signature.pgp From mike at sentex.net Tue Nov 25 09:16:57 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Nov 25 09:17:05 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <200811242107.mAOL7JB9058269@lava.sentex.ca> Message-ID: <200811251716.mAPHGreB063704@lava.sentex.ca> At 12:06 PM 11/25/2008, Adrian Chadd wrote: >2% may not sound like a lot but it starts becoming measurable savings >when the number of boxes involved is ${LARGE}. True, but then again is there such a thing as a synthetic benchmark that would have a margin of error less than 2% while representing your real world application mix? ---Mike From adrian at freebsd.org Tue Nov 25 09:30:17 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Nov 25 09:30:48 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <200811251716.mAPHGreB063704@lava.sentex.ca> References: <200811242107.mAOL7JB9058269@lava.sentex.ca> <200811251716.mAPHGreB063704@lava.sentex.ca> Message-ID: 2008/11/25 Mike Tancsa : > At 12:06 PM 11/25/2008, Adrian Chadd wrote: >> >> 2% may not sound like a lot but it starts becoming measurable savings >> when the number of boxes involved is ${LARGE}. > > True, but then again is there such a thing as a synthetic benchmark that > would have a margin of error less than 2% while representing your real world > application mix? It depends, what do you think people read when making decisions? :) Bout the only thing that could fix this is for people involved with FreeBSD to re-do the benchmark, documenting how it was done wrong, and reporting on the results. Note that I didn't say "show FreeBSD is better", at least not in the initial round. Adrian From adrian at freebsd.org Tue Nov 25 09:30:31 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Nov 25 09:30:48 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <200811242107.mAOL7JB9058269@lava.sentex.ca> References: <200811242107.mAOL7JB9058269@lava.sentex.ca> Message-ID: 2% may not sound like a lot but it starts becoming measurable savings when the number of boxes involved is ${LARGE}. 2c, Adrian 2008/11/24 Mike Tancsa : > At 03:28 PM 11/24/2008, Steven Hartland wrote: >> >> http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 >> >> Was interesting until I saw this:- >> >> "However, it's important to reiterate that all three operating systems >> were left in their stock configurations and that no additional tweaking had >> occurred." > > They all seem to be fairly close in the majority of tests. > > In the conclusion they write, "In our LAME MP3 encoding test, Ubuntu 8.10 > was the fastest followed by FreeBSD 7.1".... One needs to consider, the > difference was 2%... Thats hardly anything to get excited about, especially > if that difference can be accounted for by how much priority the scheduler > gives to a userland app vs what the system is doing etc.... > > Also, it would have been interesting to see more multithreaded work loads. > A lot of the apps they tested seemed to be single threaded, doing one job. > > ---Mike > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From rdivacky at freebsd.org Tue Nov 25 10:00:08 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Nov 25 10:00:16 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: Message-ID: <20081125173657.GA50429@freebsd.org> On Tue, Nov 25, 2008 at 12:08:27PM +0100, Ivan Voras wrote: > Steven Hartland wrote: > > http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > > > > Was interesting until I saw this:- > > > > The results seem well within expectations, for the sort of benchmarks > they did: there is little difference between the systems. Depending on > the details of how they did the benchmarks and how they processed the > results (if at all), the results can even be within the margin of error > (i.e. useless for mutual comparison except to show the systems are all > very similar). > > The benchmarks they did are mostly focused on number crunching and do > not even touch the area of system scalability to multiple CPUs, which > could have been easily done but they chose not to. Number crunching is a > bad choice for system scalability measure because down to the metal, all > systems use similar compilers and there's nothing the OS can do to I believe most of the synthetic numbers (mp3 encoding etc.) difference comes from the different version of gcc the different OS uses... From ivoras at freebsd.org Tue Nov 25 10:10:06 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 25 10:10:13 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <20081125173657.GA50429@freebsd.org> References: <20081125173657.GA50429@freebsd.org> Message-ID: Roman Divacky wrote: > On Tue, Nov 25, 2008 at 12:08:27PM +0100, Ivan Voras wrote: >> Steven Hartland wrote: >>> http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 >>> >>> Was interesting until I saw this:- >>> >> The results seem well within expectations, for the sort of benchmarks >> they did: there is little difference between the systems. Depending on >> the details of how they did the benchmarks and how they processed the >> results (if at all), the results can even be within the margin of error >> (i.e. useless for mutual comparison except to show the systems are all >> very similar). >> >> The benchmarks they did are mostly focused on number crunching and do >> not even touch the area of system scalability to multiple CPUs, which >> could have been easily done but they chose not to. Number crunching is a >> bad choice for system scalability measure because down to the metal, all >> systems use similar compilers and there's nothing the OS can do to > > I believe most of the synthetic numbers (mp3 encoding etc.) difference > comes from the different version of gcc the different OS uses... You're very likely right. Ubuntu 8.10 has gcc 4.3.x - it could make for the small difference in gzip and 7z compression performance. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20081125/e2d93278/signature.pgp From adrian at freebsd.org Tue Nov 25 12:02:41 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Nov 25 12:02:47 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <20081125173657.GA50429@freebsd.org> Message-ID: 2008/11/25 Ivan Voras : >> I believe most of the synthetic numbers (mp3 encoding etc.) difference >> comes from the different version of gcc the different OS uses... > > You're very likely right. Ubuntu 8.10 has gcc 4.3.x - it could make for > the small difference in gzip and 7z compression performance. Well, that should be a reasonably easy thing to test and feed back to the author. Adrian From adrian at freebsd.org Tue Nov 25 12:09:20 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Nov 25 12:09:26 2008 Subject: hwpmc granularity and 6.4 network performance In-Reply-To: References: Message-ID: A few things! * Since you've changed two things - hwpmc _AND_ the kernel version - you can't easily conclude which one (if any!) has any influence on Giant showing up in your top output. I suggest recompiling without hwpmc and seeing if the behaviour changes. * The gprof utility expects something resembling "time" for the sampling data, but pmcstat doesn't record time, it records "events". The counts you see in gprof are "events", so change "seconds" to "events" in your reading of the gprof output. * I don't know if the backported pmc to 6.4 handles stack call graphs or not. Easy way to check - pmcstat -R sample.out | more ; see if you just see "sample" lines or "sample" and "callgraph" lines. * I bet that ipfw_chk is a big enough hint. How big is your ipfw ruleset? :) Adrian 2008/11/24 Vadim Goncharov : > Hi! > > I've recently perfromed upgrade of busy production router from 6.2 to 6.4-PRE. > I have added two lines to my kernel config and did usual make buildkernel: > > device hwpmc # Driver (also a loadable module) > options HWPMC_HOOKS # Other necessary kernel hooks > > After rebooting with new world and kernel, I've noticed that CPU load has > slightly increased (not measured, it is different every second anyway, as > users do not genereate steady traffic), and in top -S 'swi1: net' became > often in state *Giant, but it not used to do so on 6.2, while kernel config > did not changed much, and device polling is still used. What could happen > to this? > > Another question, I've read "Sixty second HWPMC howto" and tried to find out > what exactly eats my CPU. BTW, that instruction did not apply exactly on my > machine, this is what I did: > > # cd /tmp > # pmcstat -S instructions -O /tmp/sample.out > # pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g > # gprof /boot/kernel/kernel p4-instr-retired/kernel.gmon > kernel.gmon.result > > Now in file kernel.gmon.result I see the following: > > granularity: each sample hit covers 4 byte(s) for 0.00% of 692213.00 seconds > > called/total parents > index %time self descendents called+self name index > called/total children > > > [1] 31.7 219129.00 0.00 ipfw_chk [1] > > ----------------------------------------------- > > > [...] > > Why does it show 0.00 in this column ? > > On next listing, flat profile, I see more readable listing, but columns are > empty again: > > granularity: each sample hit covers 4 byte(s) for 0.00% of 692213.00 seconds > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 31.7 219129.00 219129.00 ipfw_chk [1] > 10.4 291179.00 72050.00 bcmp [2] > 6.1 333726.00 42547.00 rn_match [3] > 2.7 352177.00 18451.00 generic_bzero [4] > 2.4 368960.00 16783.00 strncmp [5] > > OK, I can conclude from this that I should optimize my ipfw ruleset, but > that's all. I know from sources that ipfw_chk() is a big function with a > bunch of 'case's in a large 'switch'. I want to know which parts of that > switch are executed more often. It says in listing that granularity is > 4 bytes, I assume that it has a sample for each of 4-byte chunks of binary > code, so that it must have such information. My kernel is compiled with: > > makeoptions DEBUG=-g > > so kgdb does know where are instructions for each line of source code. > How can I obtain this info from profiling? It also would be useful to know > which places do calls to that bcmp() and rn_match(). > > -- > WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru > [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > From ivoras at freebsd.org Tue Nov 25 13:06:50 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 25 13:06:57 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <20081125173657.GA50429@freebsd.org> Message-ID: <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> 2008/11/25 Adrian Chadd : > 2008/11/25 Ivan Voras : > >>> I believe most of the synthetic numbers (mp3 encoding etc.) difference >>> comes from the different version of gcc the different OS uses... >> >> You're very likely right. Ubuntu 8.10 has gcc 4.3.x - it could make for >> the small difference in gzip and 7z compression performance. > > Well, that should be a reasonably easy thing to test and feed back to > the author. OTOH if the goal is to measure "operating system" performance, this must also include the compiler, libraries and all. (for example, what does Solaris default to nowadays? I think it ships with gcc but not as default). The hold on gcc 4.3 in FreeBSD is, after all, political (licencing). If FreeBSD base ever switches to LLVM+clang, this means libc will be compiled with a non-gcc compiler which will forever change the performance for simple "real world" benchmarks. From gnn at freebsd.org Tue Nov 25 15:40:24 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Nov 25 15:40:30 2008 Subject: [PATCH] pmcannotate tool In-Reply-To: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> References: <3bbf2fe10811230502t3cc52809i6ac91082f780b730@mail.gmail.com> Message-ID: At Sun, 23 Nov 2008 14:02:22 +0100, Attilio Rao wrote: > > pmcannotate is a tool that prints out sources of a tool (in C or > assembly) with inlined profiling informations retrieved by a prior > pmcstat analysis. > If compared with things like callgraph generation, it prints out > profiling on a per-instance basis and this can be useful to find, for > example, badly handled caches, too high latency instructions, etc. > > The tool usage is pretty simple: > pmcannotate [-a] [-h] [-k path] [-l level] samples.out binaryobj > > where samples.out is a pmcstat raw output and binaryobj is the binary > object that has been profiled and is accessible for (ELF) symbols > retrieving. > The options are better described in manpages but briefly: > - a: performs analysis on the assembly rather than the C source > - h: usage and informations > - k: specify a path for the kernel in order to locate correct objects for it > - l: specify a lower boundary (in total percentage time) after which > functions will be displayed nomore. > > A typical usage of pmcannotate can be some way of kernel annotation. > For example, you can follow the steps below: > 1) Generate a pmc raw output of system samples: > # pmcstat -S ipm-unhalted-core-cycles -O samples.out > 2) Copy the samples in the kernel building dir and cd there > # cp samples.out /usr/src/sys/i386/compile/GENERIC/ ; cd > /usr/src/sys/i386/compile/GENERIC/ > 3) Run pmcannotate > # pmcannotate -k . samples.out kernel.debug > kernel.ann > > In the example above please note that kernel.debug has to be used in > order to produce a C annotated source. This happens because in order > to get the binary sources we rely on the "objdump -S" command which > wants binary compiled with debugging options. > If not debugging options are present assembly analynsis is still > possible, but no C-backed one will be available. > objdump is not the only one tool on which pmcannotare rely. Infact, in > order to have it working, pmcstat needs to be present too because we > need to retrieve, from the pmcstat raw output, informations about the > sampled PCs (in particular the name of the function they live within, > its start and ending addresses). As long as currently pmcstat doesn't > return those informations, a new option has been added to the tool > (-m) which can extract (from a raw pmcstat output) all pc sampled, > name of the functions and symbol bundaries they live within. > > Also please note that pmcannotate suffers of 2 limitations. > Firstly, relying on objdump to dump the C source, with heavy > optimization levels and lots of inlines the code gets difficult to > read. Secondly, in particular on x86 but I guess it is not the only > one case, the sample is always attributed to the instruction directly > following the one that was interrupted. So in a C source view some > samples may be attributed to the line below the one you're interested > in. It's also important to keep in mind that if a line is a jump > target or the start of a function the sample really belongs elsewhere. > > The patch can be found here: > http://www.freebsd.org/~attilio/pmcannotate.diff/ > > where pmcannotate/ dir contains the code and needs to go under > /usr/src/usr.sbin/ and the patch has diffs against pmcstat and > Makefile. > > This work has been developed on the behalf of Nokia with important > feedbacks and directions from Jeff Roberson. > > Testing and feedbacks (before it hits the tree) are welcome. > Hi, First of all, this is excellent work. As soon as this and some other changes in PMC hit 7.x I'll be rolling this out to all the developers I work with. I've tested this on amd64 on HEAD, and with the changes we have talked about privately (%jx vs. %x) it works quite well. Secondly, I would like to request a feature. I would like to be able to get output in a more easily parsable format so I can write some Emacs code to highlight C code with the output. I'd like something along the lines of: path:function:line:percentage Keep up the good work! Later, George From Alexander at Leidinger.net Wed Nov 26 00:43:24 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Nov 26 00:43:31 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> Message-ID: <20081126094314.119834gt66jv0g00@webmail.leidinger.net> Quoting Ivan Voras (from Tue, 25 Nov 2008 21:46:35 +0100): > 2008/11/25 Adrian Chadd : >> 2008/11/25 Ivan Voras : >> >>>> I believe most of the synthetic numbers (mp3 encoding etc.) difference >>>> comes from the different version of gcc the different OS uses... >>> >>> You're very likely right. Ubuntu 8.10 has gcc 4.3.x - it could make for >>> the small difference in gzip and 7z compression performance. >> >> Well, that should be a reasonably easy thing to test and feed back to >> the author. > > OTOH if the goal is to measure "operating system" performance, this If you want to test OS performance and use Java programs in there to do so, you would use the same Java version, wouldn't you? They didn't. If you want to run some high performance java software and you want to know on which OS it performs best, you would test the same Java version on the OS' in question (or at least you should do that, to not compare apples and oranges). If you want to run number crunching software, you are interested in high computing throughput of your app, so you use a compiler which performs best for your code in question (which would mean probably the Intel compiler or the Portland compiler on Linux, maybe the Sun compiler on Solaris, and probably gcc on FreeBSD). You also want to optimize the code for your CPU (it makes a difference if you do floating point calculations and are allowed to use the SSEx or whatever instructions), and not some generic settings the OS comes with. The "benchmark" presented there is flawed in a lot of ways. No descrition what they really want to benchmark, no description what each subtest benchmarks (e.g. lame is performing on one CPU and occasionally performs IO, what does this benchmark mean? That your multi-CPU system is mostly idle and can be used to browse the net without that you notice any impact). Only absolute numbers and no relative performance comparision (percentage of difference). Inconsistent starting point (not the same compiler, not the same java version, ...) in case you want to promote an OS for specialized tasks (there are comments which tell FreeBSD would be good for raytracing, as the corresponding subtest was the fastest on FreeBSD), and so on. Did I overlook some part where they tell how they test? Do they calculate the average of several runs? > must also include the compiler, libraries and all. (for example, what > does Solaris default to nowadays? I think it ships with gcc but not as > default). The hold on gcc 4.3 in FreeBSD is, after all, political > (licencing). Users most of the time don't care what the reasons are, they use what is there and complain or switch if it works better somewhere else. People which care about compute intense stuff, will install their preferred compiler anyway. Bye, Alexander. -- So so is good, very good, very excellent good: and yet it is not; it is but so so. -- William Shakespeare, "As You Like It" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From markir at paradise.net.nz Wed Nov 26 00:49:47 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Wed Nov 26 00:49:55 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <200811242107.mAOL7JB9058269@lava.sentex.ca> Message-ID: <492D0A1D.9070602@paradise.net.nz> Adrian Chadd wrote: > 2% may not sound like a lot but it starts becoming measurable savings > when the number of boxes involved is ${LARGE}. > > 2c, > > Yeah, but the margin for error in these tests is undoubtedly > 2%. AFAICS this benchmark shows that Freebsd is "up there" with these guys - slower on some, faster on some - no problem. regards Mark From ivoras at freebsd.org Wed Nov 26 01:55:42 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 26 01:55:48 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <20081126094314.119834gt66jv0g00@webmail.leidinger.net> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <20081126094314.119834gt66jv0g00@webmail.leidinger.net> Message-ID: <9bbcef730811260155h156b7a6v8c88b0da51f28ee@mail.gmail.com> 2008/11/26 Alexander Leidinger : > If you want to test OS performance and use Java programs in there to do so, > you would use the same Java version, wouldn't you? They didn't. Linux: 1.6.0_0-b12 Solaris: 1.6.0_10-b33 FreeBSD: 1.6.0_07-b02 Since system have their local patches (I know FreeBSD does), I don't think it's even possible to test "exactly the same" version ;) But this also goes into the "What OS ships with" category. > If you want to run number crunching software, you are interested in high > computing throughput of your app, so you use a compiler which performs best > for your code in question (which would mean probably the Intel compiler or > the Portland compiler on Linux, maybe the Sun compiler on Solaris, and > probably gcc on FreeBSD). You also want to optimize the code for your CPU > (it makes a difference if you do floating point calculations and are allowed > to use the SSEx or whatever instructions), and not some generic settings the > OS comes with. I think they went with the "stock" configurations as that's what almost all users will use. > The "benchmark" presented there is flawed in a lot of ways. Yes. From Alexander at Leidinger.net Wed Nov 26 04:18:31 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Nov 26 04:18:38 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <9bbcef730811260155h156b7a6v8c88b0da51f28ee@mail.gmail.com> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <20081126094314.119834gt66jv0g00@webmail.leidinger.net> <9bbcef730811260155h156b7a6v8c88b0da51f28ee@mail.gmail.com> Message-ID: <20081126131814.21221p9o7j3rryjo@webmail.leidinger.net> Quoting Ivan Voras (from Wed, 26 Nov 2008 10:55:39 +0100): > 2008/11/26 Alexander Leidinger : > >> If you want to test OS performance and use Java programs in there to do so, >> you would use the same Java version, wouldn't you? They didn't. > > Linux: 1.6.0_0-b12 > Solaris: 1.6.0_10-b33 > FreeBSD: 1.6.0_07-b02 The important part is the _XX, not the -bYY. The bYY may be something we don't care about, but the _XX part is something which may cause performance differences. > Since system have their local patches (I know FreeBSD does), I don't > think it's even possible to test "exactly the same" version ;) > > But this also goes into the "What OS ships with" category. We don't ship with java at all... strictly speaking. ;) >> If you want to run number crunching software, you are interested in high >> computing throughput of your app, so you use a compiler which performs best >> for your code in question (which would mean probably the Intel compiler or >> the Portland compiler on Linux, maybe the Sun compiler on Solaris, and >> probably gcc on FreeBSD). You also want to optimize the code for your CPU >> (it makes a difference if you do floating point calculations and are allowed >> to use the SSEx or whatever instructions), and not some generic settings the >> OS comes with. > > I think they went with the "stock" configurations as that's what > almost all users will use. I fully agree. But number crunching (as benchmarked, and I'm not talking about LAME which has a 2% difference) is not something almost all users will do. Something the masses may do with the OS is not covered at all, no browser tests, no interactivity (maybe with high load in the background) tests. As I said, they don't even tell what they want to test (and as such, everything we can do is speculate... that's not something which will lead to interesting results in the thread). Bye, Alexander. -- Man must shape his tools lest they shape him. -- Arthur R. Miller http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From ohartman at zedat.fu-berlin.de Wed Nov 26 04:36:20 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Nov 26 04:36:25 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> Message-ID: <492D3E95.1000106@zedat.fu-berlin.de> Ivan Voras wrote: ... > > OTOH if the goal is to measure "operating system" performance, this > must also include the compiler, libraries and all. (for example, what > does Solaris default to nowadays? I think it ships with gcc but not as > default). The hold on gcc 4.3 in FreeBSD is, after all, political > (licencing). This is very bad to read :-( Many of my colleaugues are involved in HPC, very little of them (including myself) utilizing FreeBSD even due to the lack of fast compilers. Yes, we all can use the port, that is right, but for those not so familiar and deep inside the underlying OS, with newer, better hardware (CPUs with some interesting hardware features like SSE3/4) a on-track-following compiler like GCC 4.3 could make use of special features introduced in newer hardware and even due to better optimizations compile a faster OS. And the result, even in 3% or 5% performance gain is appreciated if model-runs taking days or weeks! Regards, Oliver > > If FreeBSD base ever switches to LLVM+clang, this means libc will be > compiled with a non-gcc compiler which will forever change the > performance for simple "real world" benchmarks. > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From ivoras at freebsd.org Wed Nov 26 06:03:54 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 26 06:04:02 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <492D3E95.1000106@zedat.fu-berlin.de> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <492D3E95.1000106@zedat.fu-berlin.de> Message-ID: O. Hartmann wrote: > Ivan Voras wrote: > ... > >> >> OTOH if the goal is to measure "operating system" performance, this >> must also include the compiler, libraries and all. (for example, what >> does Solaris default to nowadays? I think it ships with gcc but not as >> default). The hold on gcc 4.3 in FreeBSD is, after all, political >> (licencing). > > This is very bad to read :-( I agree. GPL 3 is a bit hard on the non-GPL systems (i.e. harder than GPL 2). > Many of my colleaugues are involved in HPC, very little of them > (including myself) utilizing FreeBSD even due to the lack of fast > compilers. Yes, we all can use the port, that is right, but for those > not so familiar and deep inside the underlying OS, with newer, better > hardware (CPUs with some interesting hardware features like SSE3/4) a > on-track-following compiler like GCC 4.3 could make use of special > features introduced in newer hardware and even due to better > optimizations compile a faster OS. And the result, even in 3% or 5% > performance gain is appreciated if model-runs taking days or weeks! AFAIK, gcc 4.3+ will always be available in the ports so users that need it will always have it available (it's available there now!). It's just that the base compiler will either stay 4.2, switch to something else (Roman Divacky is working on LLVM+clang), or bite the bullet (with possible workarounds for undesireable parts of GPL3) and switch to a newer gcc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20081126/0fdc0506/signature.pgp From brooks at freebsd.org Wed Nov 26 08:23:03 2008 From: brooks at freebsd.org (Brooks Davis) Date: Wed Nov 26 08:23:09 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <492D3E95.1000106@zedat.fu-berlin.de> Message-ID: <20081126162347.GA81416@lor.one-eyed-alien.net> On Wed, Nov 26, 2008 at 03:03:45PM +0100, Ivan Voras wrote: > O. Hartmann wrote: > > Ivan Voras wrote: > > ... > > > >> > >> OTOH if the goal is to measure "operating system" performance, this > >> must also include the compiler, libraries and all. (for example, what > >> does Solaris default to nowadays? I think it ships with gcc but not as > >> default). The hold on gcc 4.3 in FreeBSD is, after all, political > >> (licencing). > > > > This is very bad to read :-( > > I agree. GPL 3 is a bit hard on the non-GPL systems (i.e. harder than > GPL 2). There are several things people can do to mitigate the issues here. They can work to make it easier to completely replace the base compiler with a port. It seems not unlikely that FreeBSD distributions like PC-BSD will eventually do this. They can track GCC enhancements and when those enhancements are actually compelling make a case for an upgrade. We haven't closed the door on that possibility, but the bar is quite high given the number of FreeBSD customers who have a "no GPLv3 source in house, no exceptions!" policy. They can work on LLVM support and integration. Apple is putting a lot of effort into both llvm-gcc and clang. From the outside, it looks like they consider that their future. As such, it may well be ours. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20081126/1a3c1e3d/attachment.pgp From rdivacky at freebsd.org Wed Nov 26 12:57:42 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Nov 26 12:57:48 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: <20081126162347.GA81416@lor.one-eyed-alien.net> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <492D3E95.1000106@zedat.fu-berlin.de> <20081126162347.GA81416@lor.one-eyed-alien.net> Message-ID: <20081126205315.GA6950@freebsd.org> > They can work on LLVM support and integration. Apple is putting a lot > of effort into both llvm-gcc and clang. From the outside, it looks like > they consider that their future. As such, it may well be ours. I am doing some work on llvm+clang, it's still not very mature but looks very promising.... if you are interested contact me :) roman From joel at FreeBSD.org Thu Nov 27 02:20:29 2008 From: joel at FreeBSD.org (Joel Dahl) Date: Thu Nov 27 02:20:37 2008 Subject: FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance In-Reply-To: References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <492D3E95.1000106@zedat.fu-berlin.de> Message-ID: <492E65CC.2060900@FreeBSD.org> Ivan Voras skrev: > O. Hartmann wrote: >> Ivan Voras wrote: >> ... >> >>> OTOH if the goal is to measure "operating system" performance, this >>> must also include the compiler, libraries and all. (for example, what >>> does Solaris default to nowadays? I think it ships with gcc but not as >>> default). The hold on gcc 4.3 in FreeBSD is, after all, political >>> (licencing). >> This is very bad to read :-( > > I agree. GPL 3 is a bit hard on the non-GPL systems (i.e. harder than > GPL 2). > >> Many of my colleaugues are involved in HPC, very little of them >> (including myself) utilizing FreeBSD even due to the lack of fast >> compilers. Yes, we all can use the port, that is right, but for those >> not so familiar and deep inside the underlying OS, with newer, better >> hardware (CPUs with some interesting hardware features like SSE3/4) a >> on-track-following compiler like GCC 4.3 could make use of special >> features introduced in newer hardware and even due to better >> optimizations compile a faster OS. And the result, even in 3% or 5% >> performance gain is appreciated if model-runs taking days or weeks! > > AFAIK, gcc 4.3+ will always be available in the ports so users that need > it will always have it available (it's available there now!). It's just > that the base compiler will either stay 4.2, switch to something else Some of us are still hoping that PCC will be a viable option in the future, especially now that development has picked up again. It has a BSD-style license: http://pcc.ludd.ltu.se/ There's also an ongoing fundraiser for PCC development (in order to bring it to 1.0 release status): http://www.bsdfund.org/projects/pcc/ -- Joel From kris at FreeBSD.org Thu Nov 27 22:15:03 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Nov 27 22:15:10 2008 Subject: hwpmc / high resolution profiling kernel In-Reply-To: <20081121170643.GA41695@troll.free.org> References: <20081121170643.GA41695@troll.free.org> Message-ID: <492F8C64.7020509@FreeBSD.org> Laurent Frigault wrote: > Hi, > > I try to use hwpmc to find a net/lagg performance problem on a DELL > poweredge 2950 with dual E5440 (AMD64 7.1-PRERELEASE form yesterday) , > but it seems that those processor are not recognized by hwpmc . > Is there a known fix / work arround ? Support has recently been added in 8.0. Hopefully it will be back-ported soon. Kris From gnn at freebsd.org Fri Nov 28 09:24:02 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Fri Nov 28 09:24:09 2008 Subject: hwpmc / high resolution profiling kernel In-Reply-To: <492F8C64.7020509@FreeBSD.org> References: <20081121170643.GA41695@troll.free.org> <492F8C64.7020509@FreeBSD.org> Message-ID: At Thu, 27 Nov 2008 22:15:00 -0800, Kris Kennaway wrote: > > Laurent Frigault wrote: > > Hi, > > > > I try to use hwpmc to find a net/lagg performance problem on a DELL > > poweredge 2950 with dual E5440 (AMD64 7.1-PRERELEASE form yesterday) , > > but it seems that those processor are not recognized by hwpmc . > > Is there a known fix / work arround ? > > Support has recently been added in 8.0. Hopefully it will be > back-ported soon. > I am testing a patch presently for the latest hwpmc in 7.x Best, George From ivoras at freebsd.org Sun Nov 30 12:26:25 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Nov 30 12:26:31 2008 Subject: boot loader bug??? In-Reply-To: <492B3E3E.1000001@softhammer.net> References: <492B3E3E.1000001@softhammer.net> Message-ID: Stephen Sanders wrote: > This may be a bad list to post to for this problem but I'm having an > issue where in it appears that the boot loader fails and then overwrites > the MBR with 0. > > The system boots to : > > F1 - Linux > F3 - FreeBSD > F5 - Drive 1" > > Default: > > But then fails on "boot error". Rebooting will not even make it to the > prompt above and if one checks the MBR (via a PXE boot), it has been set > to 512 bytes of 0. > > Sound familiar? Thanks This is definitely not the right list for your question. Please take it to questions@. There has been one report that points out that some broken BIOSes change disk IDs after booting so that the loader overwrites the boot sector on the wrong disc, but this doesn't look like it's applicable to your problem. You can disable MBR modification by the boot loader with the "noupdate" options to boot0cfg(8). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20081130/bbae7123/signature.pgp