RFC: ichwd TCO v3 support
Hello, Please find a review for a patch submitted by Cas-well for ichwd TCO v3 support (Bay Trail, Rangeley,…) https://reviews.freebsd.org/D3186 Feedback welcome Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10-RC4: Got crash in igb driver
Le 10 janv. 2014 à 02:21, Yonghyeon PYUN a écrit : > On Thu, Jan 09, 2014 at 04:06:09PM +0100, Alexandre Martins wrote: >> Dear, >> >> I experience some troubles with the igb device driver on FreeBSD 10-RC4. >> >> The kernel make a pagefault in the igb_tx_ctx_setup function when accessing >> to >> a IPv6 header. >> >> The network configuration is the following: >> - box acting as an IPv6 router >> - one interface with an IPv6 (igb0) >> - another interface with a vlan, and IPv6 on it (vlan0 on igb1) >> >> Vlan Hardware tagging is set on both interfaces. >> >> The packet that cause the crash come from igb0 and go to vlan0. >> >> After investigation, i see that the mbuf is split in two. The first one >> carry >> the ethernet header, the second, the IPv6 header and data payload. >> >> The split is due to the "m_copy" done in ip6_forward, that make the mbuf not >> writable and the "M_PREPEND" in ether_output that insert the new mbuf before >> the original one. >> >> The kernel crashes only if the newly allocated mbuf is at the end of a >> memory >> page, and no page is available after this one. So, it's extremly rare. >> >> I inserted a "KASSERT" into the function (see attached patch) to check this >> behavior, and it raises on every IPv6 forwarded packet to the vlan. The >> problem disapear if i remove hardware tagging. >> >> In the commit 256200, i see that pullups has been removed. May it be related >> ? >> > > I think I introduced the header parsing code to meet controller > requirement in em(4) and Jack borrowed that code in the past but it > seems it was removed in r256200. It seems igb_tx_ctx_setup() > assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf > of the chain. > This looks wrong to me. Instead of patching each driver with pullup code we can add a generic pullup code ? - get the contiguous protocol requirement (L2, L3, L4) from underlying driver. - do the pullup > >> Can you confirm the problem ? >> > > Probably Jack can tell more about change made in r256200. It's not > easy for me to verify correctness of igb(4) at this moment. > >> Best regards >> >> -- >> Alexandre Martins >> NETASQ -- We secure IT ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Clang now the default on x86
Le 6 nov. 2012 à 15:10, Niclas Zeising a écrit : > On 11/06/12 14:26, Fabien Thomas wrote: >> >> Le 5 nov. 2012 à 20:52, Brooks Davis a écrit : >> >>> I've made clang the default on x86 systems. There will probably be a >>> few bumps as we work out the last kinks including a ABI issue for i386 >>> system libraries, but the transition is expected to be fairly smooth for >>> most users. >>> >>> Please report problems on freebsd-current or freebsd-toolchain. >> >> Great to see that happening! >> >> I've started rebuilding in a VM with 1Gb memory and buildworld failed because >> no memory was available for the compiler (c++). It seems that Clang use a >> lot more memory? >> Do you have a minimum required memory size to finish a buildworld (amd64). >> >> Fabien > > I have no trouble doing a -j8 build with 2GB memory, so 1GB should work fine, > unless you spawn a lot of parallel builds or do a lot of other stuff at the > same time. I've used -j4 with 1Gb in an idle VM. I've now bumped to 2Gb and restarted it. > Regards! > -- > Niclas Zeising ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Clang now the default on x86
Le 5 nov. 2012 à 20:52, Brooks Davis a écrit : > I've made clang the default on x86 systems. There will probably be a > few bumps as we work out the last kinks including a ABI issue for i386 > system libraries, but the transition is expected to be fairly smooth for > most users. > > Please report problems on freebsd-current or freebsd-toolchain. Great to see that happening! I've started rebuilding in a VM with 1Gb memory and buildworld failed because no memory was available for the compiler (c++). It seems that Clang use a lot more memory? Do you have a minimum required memory size to finish a buildworld (amd64). Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: polling's future [was: Re: Dynamic Ticks/HZ]
Le 6 nov. 2012 à 12:42, Andre Oppermann a écrit : > On 06.11.2012 12:02, Fabien Thomas wrote: >>>> >>> >>> Hi Luigi, >>> >>> do you agree on polling having outlived its usefulness in the light >>> of interrupt moderating NIC's and SMP complications/disadvantages? >>> >> If you have only one interface yes polling is not really necessary. >> >> If you have 10 interfaces the interrupt moderation threshold is hard to find >> to not saturate the system. >> Doing polling at 8000hz in that case is a lot better regarding global >> interrupt level. > > OK. Is the problem the interrupt load itself, or the taskqueues? Both, interrupt load will be higher if you want to keep latency low and taskqueue is just polling without global fairness (if you have 10 interface with 6 core this will give you 60 taskqueue). If you poll 16 packets at a time from each interface, processing are more fair. > >> The problem is that in the current state polling does not work well and >> people remember >> the good old time where polling was better. > > Indeed. > >> rstone@ and myself have made some improvement to polling. >> >> You can find a diff here for 8.3 with updated intel driver : >> http://people.freebsd.org/~fabient/polling/patch-pollif_8.3_11052012 >> >> - support multiqueue for ixgbe, igb, em. >> - compat API for old driver >> - keep interrupt for link / status >> - user core mapping / auto mapping >> - deadline to keep cpu available >> - integrated to netisr >> - deferred packet injection with optional prefetching > > This is a number of interesting but sometimes only tangentially > related features. Lets focus on the network cpu monopolization > issue first. This is what deadline is: Deadline is the maximum time spend over the scheduling period in percent. Scheduling period is a fraction of the polling period (100hz by default). Each round is measured to estimate time of a round (if some packet require crypto load will increase for example) and processing stop when the deadline is reached (If no thread want to run deadline is extended). Hope it is more clear. Sample: ~$ sysctl kern.pollif kern.pollif.map: kern.pollif.stats_clear: 0 kern.pollif.stats: Work queue 0: CPU load = 0 % pass = 80 run overflow = 0 Interface ix1.0 resched rx = 0 Interface ix0.0 resched rx = 0 Work queue 1: CPU load = 0 % pass = 80 run overflow = 0 Interface ix1.1 resched rx = 0 Interface ix0.1 resched rx = 0 Work queue 2: CPU load = 0 % pass = 80 run overflow = 0 Interface ix1.2 resched rx = 0 Interface ix0.2 resched rx = 0 Work queue 3: CPU load = 0 % pass = 80 run overflow = 0 Interface ix1.3 resched rx = 0 Interface ix0.3 resched rx = 0 kern.pollif.deadline: 80 kern.pollif.register_check: 10 kern.pollif.sched_div: 80 kern.pollif.packet_per_round: 16 kern.pollif.handlers: 8 > >> Performance are on par with interrupt but you can keep a system alive more >> easily >> by accounting all network processing for the deadline (with direct dispatch). > > Would you be willing to work a solution with me with a load aware > taskqueue as I proposed in a recent email to Luigi? That way we > don't need special cases or features or even a normal server under > DDoS wouldn't go down. The main problem of current version I have is that you consume a little CPU when idle (99.8% idle with top, < 0.5% with PMC using CPU_CLK_UNHALTED.THREAD_P). To solve that, kickstarting the polling with interrupt is a good idea to reduce it but i've never tested so why not. > > -- > Andre > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: polling's future [was: Re: Dynamic Ticks/HZ]
>> > > Hi Luigi, > > do you agree on polling having outlived its usefulness in the light > of interrupt moderating NIC's and SMP complications/disadvantages? > If you have only one interface yes polling is not really necessary. If you have 10 interfaces the interrupt moderation threshold is hard to find to not saturate the system. Doing polling at 8000hz in that case is a lot better regarding global interrupt level. The problem is that in the current state polling does not work well and people remember the good old time where polling was better. rstone@ and myself have made some improvement to polling. You can find a diff here for 8.3 with updated intel driver : http://people.freebsd.org/~fabient/polling/patch-pollif_8.3_11052012 - support multiqueue for ixgbe, igb, em. - compat API for old driver - keep interrupt for link / status - user core mapping / auto mapping - deadline to keep cpu available - integrated to netisr - deferred packet injection with optional prefetching Performance are on par with interrupt but you can keep a system alive more easily by accounting all network processing for the deadline (with direct dispatch). Fabien > And also that in its current state it is providing no benefit, if > not negative, and that fixing it for the current world-order is major > undertaking that's not really beneficial considering superior > alternatives? > > That nobody is maintaining it and taking care of and fixing the frequent > problem, performance and bug reports? > > Additionally it misleads people without deep network knowledge to > compile it into their kernel under wrong assumptions and see a > degradation of performance, if not other side effects? > > Under these considerations I propose to remove polling support from > current and 10.0 in lieu of upcoming superior alternatives (netmap > enabled features). It was a great feature in the past but is beyond > retirement and should live a peaceful live in the attic. > > -- > Andre > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]hwpmc update for sandybridge-e
Le 18 oct. 2012 à 03:07, hiren panchasara a écrit :
> + Sean - who got dropped from the chain somehow.
>
> On Wed, Oct 17, 2012 at 6:01 PM, Jim Harris wrote:
> On Wed, Oct 17, 2012 at 5:55 PM, hiren panchasara
> wrote:
> >
> >
> > On Wed, Oct 17, 2012 at 5:12 PM, hiren panchasara
> > wrote:
> >>
> >>
> >>
> >> On Wed, Oct 17, 2012 at 5:00 PM, Jim Harris wrote:
> >>>
> >>> On Wed, Oct 17, 2012 at 3:57 PM, hiren panchasara
> >>> wrote:
> >>> >
> >>>
> >>> >
> >>> >
> >>> > Thanks for the pointers Jim!
> >>> >
> >>> > It seems that everything works now with:
> >>> >
> >>> > http://www.strugglingcoder.info/patches/hwpmc_sbx_3.txt
> >
> >
> > I've also made following change in existing sandybridge (not xeon :-) )
> > mappings.
> > Let me know if that looks reasonable.
> >
> >
> > @@ -2772,7 +2777,7 @@
> > __PMC_EV_ALIAS("MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_NONE",
> > IAP_EVENT_D2H_08H)\
> > __PMC_EV_ALIAS("MEM_LOAD_UOPS_LLC_HIT_RETIRED.LLC_MISS",
> > IAP_EVENT_D4H_02H)\
> > __PMC_EV_ALIAS("L2_TRANS.DEMAND_DATA_RD", IAP_EVENT_F0H_01H)
> > \
> > -__PMC_EV_ALIAS("L2_TRANS.RF0", IAP_EVENT_F0H_02H)
> > \
> > +__PMC_EV_ALIAS("L2_TRANS.RFO", IAP_EVENT_F0H_02H)
> > \
> > __PMC_EV_ALIAS("L2_TRANS.CODE_RD", IAP_EVENT_F0H_04H)
> > \
> > __PMC_EV_ALIAS("L2_TRANS.ALL_PF", IAP_EVENT_F0H_08H)
> > \
> > __PMC_EV_ALIAS("L2_TRANS.L1D_WB", IAP_EVENT_F0H_10H)
> > \
>
> This is a reasonable change, but it should be part of a separate commit.
>
> Sure, I will separate it out.
>
> If there are no further comments, can I ask Sean to commit on my behalf?
Can you do the man page to include both in the commit?
Except that point seems good to me.
Thanks!
Fabien
>
> Thanks,
> Hiren
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]hwpmc update for sandybridge-e
Le 16 oct. 2012 à 02:49, hiren panchasara a écrit : > > > On Mon, Oct 15, 2012 at 1:12 AM, Fabien Thomas > wrote: > > Le 13 oct. 2012 à 00:54, hiren panchasara a écrit : > > > > > > > On Fri, Oct 5, 2012 at 1:05 AM, Fabien Thomas > > wrote: > > > > Le 5 oct. 2012 à 10:00, Fabien Thomas a écrit : > > > > > > > > Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : > > > > > >> So, I did the bear minimum and kind of hacked things together without > > >> understanding precisely what I was doing, and I was able to massage the > > >> sandybridge-e CPUs into giving me some basic functions. > > >> > > >> Comments or concerns before I commit this? > > >> > > >> http://people.freebsd.org/~sbruno/pmc_sandybridge.txt > > > > > > Hi Sean, > > > > > > The only modification required is this one > > > http://svnweb.freebsd.org/base?view=revision&revision=237196 > > > > > > but davide@ removed it for a problem that need to be looked at. > > > > Looking at the doc this CPU require a full set of PMC as the list of event > > are different. > > So this mean full manpage, full event list, … > > > > Doc: > > " > > The events in Table 19-3 apply to > > processors with CPUID signature of DisplayFamily_DisplayModel encoding with > > the > > following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to > > processors > > with CPUID signature 06_2AH. The events in Table 19-5 apply to processors > > with > > CPUID signature 06_2DH. > > " > > > > Required change will be the same as this commit if you want to look at it: > > http://svnweb.freebsd.org/base?view=revision&revision=240164 > > > > Hi All, > > > > With help of Sean, I've prepared another semi-working patch: > > http://www.strugglingcoder.info/patches/hwpmc_sbx_1.txt > > Great, i've quickly looked at the patch: > > I'm not sure to understand why you have removed code in your case for uncore. > If you dont want to support remove it like for ivy bridge. > > Thanks Fabien for getting back quickly. As I am not clear about uncore > support, I've removed it entirely as you suggested. I've tried to incorporate > other comments too. > > New set of diffs, pmccontrol and pmctest.py results are here: > > http://www.strugglingcoder.info/patches/hwpmc_sbx_2.txt > http://www.strugglingcoder.info/patches/pmccontrol_2.txt > http://www.strugglingcoder.info/patches/pmctestpy_2.txt > > I now have following event counters failing from pmctest.py script: > CYCLE_ACTIVITY.CYCLES_L2_PENDING > I think you missed IAP_F_FM. I will look at the new diff later. > BACLEARS.ANY > L2_TRANS.DEMAND_DATA_RD > L2_TRANS.RF0 > SQ_MISC.SPLIT_LOCK > I am not quite sure why these are failing. Will continue looking into it. > > Appreciate your help, > Hiren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]hwpmc update for sandybridge-e
Le 13 oct. 2012 à 00:54, hiren panchasara a écrit : > > > On Fri, Oct 5, 2012 at 1:05 AM, Fabien Thomas > wrote: > > Le 5 oct. 2012 à 10:00, Fabien Thomas a écrit : > > > > > Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : > > > >> So, I did the bear minimum and kind of hacked things together without > >> understanding precisely what I was doing, and I was able to massage the > >> sandybridge-e CPUs into giving me some basic functions. > >> > >> Comments or concerns before I commit this? > >> > >> http://people.freebsd.org/~sbruno/pmc_sandybridge.txt > > > > Hi Sean, > > > > The only modification required is this one > > http://svnweb.freebsd.org/base?view=revision&revision=237196 > > > > but davide@ removed it for a problem that need to be looked at. > > Looking at the doc this CPU require a full set of PMC as the list of event > are different. > So this mean full manpage, full event list, … > > Doc: > " > The events in Table 19-3 apply to > processors with CPUID signature of DisplayFamily_DisplayModel encoding with > the > following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to > processors > with CPUID signature 06_2AH. The events in Table 19-5 apply to processors with > CPUID signature 06_2DH. > " > > Required change will be the same as this commit if you want to look at it: > http://svnweb.freebsd.org/base?view=revision&revision=240164 > > Hi All, > > With help of Sean, I've prepared another semi-working patch: > http://www.strugglingcoder.info/patches/hwpmc_sbx_1.txt Great, i've quickly looked at the patch: I'm not sure to understand why you have removed code in your case for uncore. If you dont want to support remove it like for ivy bridge. some minor: +#define sandybridge_xeon_aliases core2_aliases +#define sandybridge_xeon_aliases_without_iaf core2_aliases_without_iaf + case PMC_CPU_INTEL_SANDYBRIDGE_XEON: + pmc_class_table[n++] = &ucf_class_table_descr; + pmc_class_table[n++] = &sandybridgeuc_class_table_descr; + PMC_MDEP_INIT_INTEL_V2(sandybridge_xeon); + break; keep this sorted. > > I still haven't written the man page. I wanted to get some feedback > (bashing/yelling) before spending more time on this. > > I am not quite sure how to handle uncore events. I've put ugly hack to avoid > wrmsr/rdmsr for this particular set of processors. I bet there are better > ways to handle this situation. (in hwpmc_uncore.c) > > Here is the o/p of "pmccontrol -L": > http://www.strugglingcoder.info/patches/pmccontrol_1.txt > > I've run the pmctest.py script (by gnn): > http://www.strugglingcoder.info/patches/pmctestpy_1.txt > > I am seeing "invalid argument" for some events. I've tried to check > pmc_events.h to see that those events are listed. Not sure what else I should > check. > Seems you need to double check the event list: "pmcstat: ERROR: Cannot allocate process-mode pmc with specification "L2_L1D_WB_RQSTS.MISS": Invalid argument" map to 28 01 which is not in the table: IAPDESCR(28H, 0x28, IAP_M_CORE | IAP_M_MESI, IAP_F_ALLCPUSCORE2), IAPDESCR(28H_01H, 0x28, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_IB), IAPDESCR(28H_02H, 0x28, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM), -IAPDESCR(28H_04H, 0x28, 0x04, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB), -IAPDESCR(28H_08H, 0x28, 0x08, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB), +IAPDESCR(28H_04H, 0x28, 0x04, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | + IAP_F_SBX), +IAPDESCR(28H_08H, 0x28, 0x08, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | + IAP_F_SBX), IAPDESCR(28H_0FH, 0x28, 0x0F, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_IB), > I've also tried to follow the commands Fabien listed for testing on > http://freebsd.1045724.n5.nabble.com/CFT-hwpmc-support-for-Intel-Ivy-Bridge-tp5740299p5740577.html > > I am getting panic on following: > - Soft counter: > pmcstat -SPAGE_FAULT.ALL -w4 -T > Not related but need to be investigated. (I will look at it.) > panic details: > -bash-4.2$ panic: userret: Returning with with pinned thread > cpuid = 22 > KDB: enter: panic > [ thread pid 4084 tid 100302 ] > Stopped at kdb_enter+0x3b: movq$0,0xa74122(%rip) > db> bt > Tracing pid 4084 tid 100302 td 0xfe0016dbc000 > kdb_enter() at kdb_enter+0x3b > panic() at panic+0x1d1 > userret() at userret+0x15c > trap() at trap+0x200 > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0x8013d86a0, rsp = 0x7fffd4b0, rbp = 0x
Re: [CFT]hwpmc update for sandybridge-e
Le 5 oct. 2012 à 10:00, Fabien Thomas a écrit : > > Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : > >> So, I did the bear minimum and kind of hacked things together without >> understanding precisely what I was doing, and I was able to massage the >> sandybridge-e CPUs into giving me some basic functions. >> >> Comments or concerns before I commit this? >> >> http://people.freebsd.org/~sbruno/pmc_sandybridge.txt > > Hi Sean, > > The only modification required is this one > http://svnweb.freebsd.org/base?view=revision&revision=237196 > > but davide@ removed it for a problem that need to be looked at. Looking at the doc this CPU require a full set of PMC as the list of event are different. So this mean full manpage, full event list, … Doc: " The events in Table 19-3 apply to processors with CPUID signature of DisplayFamily_DisplayModel encoding with the following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to processors with CPUID signature 06_2AH. The events in Table 19-5 apply to processors with CPUID signature 06_2DH. " Required change will be the same as this commit if you want to look at it: http://svnweb.freebsd.org/base?view=revision&revision=240164 > > > Fabien >> >> Sean >> >> p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. >> >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]hwpmc update for sandybridge-e
Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : > So, I did the bear minimum and kind of hacked things together without > understanding precisely what I was doing, and I was able to massage the > sandybridge-e CPUs into giving me some basic functions. > > Comments or concerns before I commit this? > > http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Hi Sean, The only modification required is this one http://svnweb.freebsd.org/base?view=revision&revision=237196 but davide@ removed it for a problem that need to be looked at. Fabien > > Sean > > p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] hwpmc support for Intel Ivy Bridge
Le 5 sept. 2012 à 20:12, Peter Grehan a écrit : > Another system: > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3392.36-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 > Features=0xbfebfbff > Features2=0x7fbae3ff > AMD Features=0x28100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > > All pmcstat tests worked. The pmctest.py script failed with SOFT the same way > as bapt@'s, but all subsequent tests passed. Thanks! Not a problem, the script parse pmccontrol and run pmcstat with each value except section but SOFT is not in the exclusion list. > > pmccontrol -L output appended. > > later, > > Peter. > > # ./pmccontrol -L > SOFT > CLOCK.STAT > CLOCK.HARD > LOCK.FAILED > PAGE_FAULT.WRITE > PAGE_FAULT.READ > PAGE_FAULT.ALL > TSC > TSC > IAP > LD_BLOCKS.STORE_FORWARD > MISALIGN_MEM_REF.LOADS > MISALIGN_MEM_REF.STORES > LD_BLOCKS_PARTIAL.ADDRESS_ALIAS > DTLB_LOAD_MISSES.DEMAND_LD_MISS_CAUSES_A_WALK > DTLB_LOAD_MISSES.DEMAND_LD_WALK_COMPLETED > DTLB_LOAD_MISSES.DEMAND_LD_WALK_DURATION > UOPS_ISSUED.ANY > UOPS_ISSUED.FLAGS_MERGE > UOPS_ISSUED.SLOW_LEA > UOPS_ISSUED.SINGLE_MUL > ARITH.FPU_DIV_ACTIVE > L2_RQSTS.DEMAND_DATA_RD_HIT > L2_RQSTS.ALL_DEMAND_DATA_RD > L2_RQSTS.RFO_HITS > L2_RQSTS.RFO_MISS > L2_RQSTS.ALL_RFO > L2_RQSTS.CODE_RD_HIT > L2_RQSTS.CODE_RD_MISS > L2_RQSTS.ALL_CODE_RD > L2_RQSTS.PF_HIT > L2_RQSTS.PF_MISS > L2_RQSTS.ALL_PF > L2_STORE_LOCK_RQSTS.MISS > L2_STORE_LOCK_RQSTS.HIT_M > L2_STORE_LOCK_RQSTS.ALL > L2_L1D_WB_RQSTS.MISS > L2_L1D_WB_RQSTS.HIT_E > L2_L1D_WB_RQSTS.HIT_M > L2_L1D_WB_RQSTS.ALL > LONGEST_LAT_CACHE.REFERENCE > LONGEST_LAT_CACHE.MISS > CPU_CLK_UNHALTED.THREAD_P > CPU_CLK_THREAD_UNHALTED.REF_XCLK > L1D_PEND_MISS.PENDING > DTLB_STORE_MISSES.MISS_CAUSES_A_WALK > DTLB_STORE_MISSES.WALK_COMPLETED > DTLB_STORE_MISSES.WALK_DURATION > DTLB_STORE_MISSES.STLB_HIT > LOAD_HIT_PRE.SW_PF > LOAD_HIT_PRE.HW_PF > L1D.REPLACEMENT > MOVE_ELIMINATION.INT_NOT_ELIMINATED > MOVE_ELIMINATION.SIMD_NOT_ELIMINATED > MOVE_ELIMINATION.INT_ELIMINATED > MOVE_ELIMINATION.SIMD_ELIMINATED > CPL_CYCLES.RING0 > CPL_CYCLES.RING123 > RS_EVENTS.EMPTY_CYCLES > TLB_ACCESS.LOAD_STLB_HIT > OFFCORE_REQUESTS_OUTSTANDING.DEMAND_DATA_RD > OFFCORE_REQUESTS_OUTSTANDING.DEMAND_CODE_RD > OFFCORE_REQUESTS_OUTSTANDING.DEMAND_RFO > OFFCORE_REQUESTS_OUTSTANDING.ALL_DATA_RD > LOCK_CYCLES.SPLIT_LOCK_UC_LOCK_DURATION > LOCK_CYCLES.CACHE_LOCK_DURATION > IDQ.EMPTY > IDQ.MITE_UOPS > IDQ.DSB_UOPS > IDQ.MS_DSB_UOPS > IDQ.MS_MITE_UOPS > IDQ.MS_UOPS > IDQ.ALL_DSB_CYCLES_ANY_UOPS > IDQ.ALL_DSB_CYCLES_4_UOPS > IDQ.ALL_MITE_CYCLES_ANY_UOPS > IDQ.ALL_MITE_CYCLES_4_UOPS > IDQ.MITE_ALL_UOPS > ICACHE.MISSES > ITLB_MISSES.MISS_CAUSES_A_WALK > ITLB_MISSES.WALK_COMPLETED > ITLB_MISSES.WALK_DURATION > ITLB_MISSES.STLB_HIT > ILD_STALL.LCP > ILD_STALL.IQ_FULL > BR_INST_EXEC.COND > BR_INST_EXEC.DIRECT_JMP > BR_INST_EXEC.INDIRECT_JMP_NON_CALL_RET > BR_INST_EXEC.RETURN_NEAR > BR_INST_EXEC.DIRECT_NEAR_CALL > BR_INST_EXEC.INDIRECT_NEAR_CALL > BR_INST_EXEC.NONTAKEN > BR_INST_EXEC.TAKEN > BR_INST_EXEC.ALL_BRANCHES > BR_MISP_EXEC.COND > BR_MISP_EXEC.INDIRECT_JMP_NON_CALL_RET > BR_MISP_EXEC.RETURN_NEAR > BR_MISP_EXEC.DIRECT_NEAR_CALL > BR_MISP_EXEC.INDIRECT_NEAR_CALL > BR_MISP_EXEC.NONTAKEN > BR_MISP_EXEC.TAKEN > BR_MISP_EXEC.ALL_BRANCHES > IDQ_UOPS_NOT_DELIVERED.CORE > UOPS_DISPATCHED_PORT.PORT_0 > UOPS_DISPATCHED_PORT.PORT_1 > UOPS_DISPATCHED_PORT.PORT_2_LD > UOPS_DISPATCHED_PORT.PORT_2_STA > UOPS_DISPATCHED_PORT.PORT_2 > UOPS_DISPATCHED_PORT.PORT_3_LD > UOPS_DISPATCHED_PORT.PORT_3_STA > UOPS_DISPATCHED_PORT.PORT_3 > UOPS_DISPATCHED_PORT.PORT_4 > UOPS_DISPATCHED_PORT.PORT_5 > RESOURCE_STALLS.ANY > RESOURCE_STALLS.RS > RESOURCE_STALLS.SB > RESOURCE_STALLS.ROB > DSB2MITE_SWITCHES.COUNT > DSB2MITE_SWITCHES.PENALTY_CYCLES > DSB_FILL.EXCEED_DSB_LINES > ITLB.ITLB_FLUSH > OFFCORE_REQUESTS.DEMAND_DATA_RD > OFFCORE_REQUESTS.DEMAND_CODE_RD > OFFCORE_REQUESTS.DEMAND_RFO > OFFCORE_REQUESTS.ALL_DATA_RD > UOPS_EXECUTED.THREAD > UOPS_EXECUTED.CORE > OFF_CORE_RESPONSE_0 > OFF_CORE_RESPONSE_1 > TLB_FLUSH.DTLB_THREAD > TLB_FLUSH.STLB_ANY > INST_RETIRED.ANY_P > INST_RETIRED.ALL > OTHER_ASSISTS.AVX_STORE > OTHER_ASSISTS.AVX_TO
Re: [CFT] hwpmc support for Intel Ivy Bridge
> > Hi, > > here are the results > > # pmccontrol -L > SOFT >CLOCK.STAT >CLOCK.HARD >LOCK.FAILED >PAGE_FAULT.WRITE >PAGE_FAULT.READ >PAGE_FAULT.ALL > Seems that the CPU was not detected can you dump the dmesg with CPU: section ? As Davide ask, if you are in a VM pmc are not usable in the virtualized HW. > # pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -w1 -T > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > "OFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY": Invalid argument > > # pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > "INSTR_RETIRED_ANY": Invalid argument > > # pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > "INSTR_RETIRED_ANY": Invalid argument > > # pmcstat -SPAGE_FAULT.ALL -w4 -T > (This one seems to work correctly > > # pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -n200 > -SCPU_CLK_UNHALTED.THREAD_P -n200 -S INSTR_RETIRED_ANY -SPAGE_FAULT > pmcstat: ERROR: Cannot allocate system-mode pmc with specification > "OFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY": Invalid argument > > The pmctest.py fails: > # ./test/hwpmc/pmctest.py > Traceback (most recent call last): > File "./test/hwpmc/pmctest.py", line 94, in >main() > File "./test/hwpmc/pmctest.py", line 81, in main >stdout=PIPE) > File "/usr/local/lib/python2.7/subprocess.py", line 679, in __init__ >errread, errwrite) > File "/usr/local/lib/python2.7/subprocess.py", line 1249, in _execute_child >raise child_exception > TypeError: execv() arg 2 must contain only strings > > > regards, > Bapt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] hwpmc support for Intel Ivy Bridge
Le 3 sept. 2012 à 23:23, Baptiste Daroussin a écrit : > On Mon, Sep 03, 2012 at 02:04:21PM +0200, Fabien Thomas wrote: >> Hi, >> >> Find a patch that add Intel Ivy Bridge support to hwpmc(9). >> The patch also support offcore RSP token for Sandy Bridge. >> Note: No uncore support. >> >> Tested on: >> Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (2494.35-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 >> >> http://people.freebsd.org/~fabient/patch-hwpmc_ivy_bridge_head >> >> cd /usr/src && patch -p0 < patch-hwpmc_ivy_bridge_head >> and rebuild world. >> >> >> Fabien > > World building, I'll keep you in touch > > Is there any particulat testing, I can do other than using the new world? Thanks for testing! Yes you can test it quickly using top mode for example: kldload hwpmc pmccontrol -L to list all events some test: - offcore pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -w1 -T - unhalted cycle (programmable counter) pmcstat -n200 -SCPU_CLK_UNHALTED.THREAD_P -w4 -T - INSTR_RETIRED_ANY (fixed counter) pmcstat -n200 -S INSTR_RETIRED_ANY -w4 -T - Soft counter: pmcstat -SPAGE_FAULT.ALL -w4 -T all at the same time (and change view by pressing 'p': pmcstat -SOFF_CORE_RESPONSE_0,rsp=REQ_DMND_DATA_RD+RES_ANY -n200 -SCPU_CLK_UNHALTED.THREAD_P -n200 -S INSTR_RETIRED_ANY -SPAGE_FAULT.ALL -w1 -T all events are described in the man page pmc.ivybridge > > regards, > Bapt
[CFT] hwpmc support for Intel Ivy Bridge
Hi, Find a patch that add Intel Ivy Bridge support to hwpmc(9). The patch also support offcore RSP token for Sandy Bridge. Note: No uncore support. Tested on: Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (2494.35-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 http://people.freebsd.org/~fabient/patch-hwpmc_ivy_bridge_head cd /usr/src && patch -p0 < patch-hwpmc_ivy_bridge_head and rebuild world. Fabien
Re: panic: incorrect npmc count
Le 9 mai 2012 à 16:30, Ryan Stone a écrit : > On Wed, May 9, 2012 at 1:16 AM, Peter Jeremy wrote: >> [This may be a duplicate because I forgot to update my subscription >> after changing address but I've also corrected a typo] >> >> (I've copied fabient@ because r233628 appears to have been the last >> commit in this area). >> >> I've just updated a P4 test box from r232545 to r235127 and it now >> panics during boot: >> panic: [intel,202] incorrect npmc count 35 >> Looking at sys/dev/hwpmc/hmpmc_intel.c line 202, the expected >> npmc count is 19. >> >> When I look at the actual code in pmc_intel_initialize(): >> pmc_mdep_alloc() initialises pmd_npmc to zero and then increments >> it by SOFT_NPMCS (16) in pmc_soft_initialize(). >> pmc_tsc_initialize() then increments it by TSC_NPMCS (1) >> pmc_p4_initialize() then increments it by P4_NPMCS (18) >> This totals 35 (as per the panic message). >> >> Can someone explain the KASSERT() that expects 19 - it boils down to >> KASSERT(0+16+1+18 == 1+18, ...) >> I gather not many people are running -current on a P4. >> >> -- >> Peter Jeremy > > That KASSERT is just out of date. The soft PMC support is quite new. > I would just drop the KASSERT entirely; it really isn't adding any > value. Back from vacation. Yes, as Ryan stated the KASSERT is out of date and i've missed the update / removal with soft PMC. Fixed with r235229. Fabien
Re: Some performance measurements on the FreeBSD network stack
>> > > I have a patch that has been sitting around for a long time due to > review cycle latency that caches a pointer to the rtentry (and > llentry) in the the inpcb. Before each use the rtentry is checked > against a generation number in the routing tree that is incremented on > every routing table update. Hi Kip, Is there a public location for the patch ? What can be done to speedup the commit: testing ? Fabien
Re: [RFC] VIA south bridge watchdog support
> Hi, > > If someone want to look at I've added support for VIA south bridge watchdog. > It has been tested on VX900 but should works with VX800, VX855, CX700. > > http://people.freebsd.org/~fabient/patch-watchdog-via-rev1 > Posted rev2 : http://people.freebsd.org/~fabient/patch-watchdog-via-rev2 - add / test VT8251 - man page update - reset FIRED bit when detected Maybe other south bridge supported but feedback is needed. Fabien___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[RFC] VIA south bridge watchdog support
Hi, If someone want to look at I've added support for VIA south bridge watchdog. It has been tested on VX900 but should works with VX800, VX855, CX700. http://people.freebsd.org/~fabient/patch-watchdog-via-rev1 Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Deadlock on stable fixed on head
I'm debugging a deadlock on FreeBSD that is not on head but on 7.3, 8.2... Maybe someone will have an idea on what patch fixed it. Context: 1 - On a UP machine (Multicore without SMP option or UP with SMP). 2 - When using device apic (more on this later) 3 - Using DEVICE_POLLING (more on this later) 4- HZ set to 2000 Launching a CPU intensive task freeze the box (burnP6 from cpuburn port) nearly 100% chance of success. This can be reproduced on very different HW so it is software related. Reproduced on i386 / amd64. Current analysis status: 1 - having >1 CPU and SMP enabled avoid the deadlock 2 - apic enable the problem when using critical_exit (using isa/clock does not have critical_exit and then works) 3 - this is not the polling itself but the scheduling of the thread only 4 - no idea So to sum up it seems related to a scheduling issue. I've got some info from a 8.2 that can enter ddb (7.3 will not enter ddb) [1] If someone have an idea / fixed something related, etc... tell me :) [1] http://people.freebsd.org/~fabient/burnP6_deadlock.txt -- Fabien Thomas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSL 1.0.0d for Freebsd HEAD
> Dears, > > After several research, i have removed the problematic part. > > You can find the new version here: > > http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d > It will be great to have it in 9.0. To do that how is it possible rebuild the port for all platform with openssl 1.0.0d in base? Is there some people against that inclusion? I can take the task to commit the patch but I will need direction on what to check from people that have done that before. simon@ is not available for that task so if other people are available to help feel free to send me an email. Fabien___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Profiling code execution on amd64?
Last time i've used it it was working but I dont think it is really useful now (from my POV) because you cant have a global view of the system with it and all other reports overlap. With the current state you have: - top mode for fast lookup - text output (replace gprof for me) - kcachegrind (calltree) for in depth analysis - gprof Fabien > On Fri, Jan 14, 2011 at 10:10 PM, Steve Kargl > wrote: >> On Fri, Jan 14, 2011 at 03:40:46PM -0500, George Neville-Neil wrote: >>> >>> On Jan 13, 2011, at 23:05 , Steve Kargl wrote: >>> On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote: > I would suggest using hwpmc for profiling: > > # kldload hwpmc > # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration > # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt > > > You can also get pmcstat to generate gprof-compatible output with -g, > but I never use the mode so I'm really not sure what it gives you. I > think that you have to run gprof on the output or something, but don't > hold me to that. Thanks. I'll give it a try, but my initial attempt seems to indicate that one needs to be root to use hwpmc. laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration pmcstat: ERROR: Cannot allocate system-mode pmc with specification "unhalted-cycles": Operation not permitted >>> >>> You only need to be root to profile the kernel or someone else's process. >>> >>> This tutorial might help: >>> >>> www.dcbsdcon.org/speakers/slides/neville-neil_dcbsdcon2009.pdf >>> >> >> Thanks. I'll look at the tutorial. Meanwhile, should gprof >> be removed from the base system because it appears broken? > > Instead of just removing things, why not determine why things are > broken and try to fix them? > -Garrett > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
OpenSSL 1.0
Is there any plan to import OpenSSL 1.0 into the tree? Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TCP loopback socket fusing
On 14 sept. 2010, at 17:41, Andre Oppermann wrote: > On 14.09.2010 11:18, Fabien Thomas wrote: >> Great, >> >> This will maybe kill the long time debate about "my loopback is slow vs >> linux" >> To have the best of both world what about a socket option to enable/disable >> fusing: >> can be useful when you need to see some connection "packetized". > > A sysctl to that effect is already in the patch. yes, i'm just wondering on a per connection setting. > > -- > Andre > >> Fabien >> >> On 13 sept. 2010, at 13:33, Andre Oppermann wrote: >> >>> When a TCP connection via loopback back to localhost is made the whole >>> send, segmentation and receive path (with larger packets though) is still >>> executed. This has some considerable overhead. >>> >>> To short-circuit the send and receive sockets on localhost TCP connections >>> I've made a proof-of-concept patch that directly places the data in the >>> other side's socket buffer without doing any packetization and other >>> protocol >>> overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, >>> ACK) and shutdown are still handled by normal TCP segments via loopback so >>> that firewalling stills works. The actual payload data during the session >>> won't be seen and the sequence numbers don't move other than for SYN and >>> FIN. >>> The sequence are remain valid though. Obviously tcpdump won't see any data >>> transfers either if the connection has fused sockets. >>> >>> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable >>> operation and a rough doubling of the throughput on loopback connections. >>> I've tested most socket teardown cases and it behaves fine. I'm not >>> entirely >>> sure I've got all possible path's but the way it is integrated should >>> properly >>> defuse the sockets in all situations. >>> >>> Testers and feedback wanted: >>> >>> http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff >>> >>> -- >>> Andre >>> >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TCP loopback socket fusing
Great, This will maybe kill the long time debate about "my loopback is slow vs linux" To have the best of both world what about a socket option to enable/disable fusing: can be useful when you need to see some connection "packetized". Fabien On 13 sept. 2010, at 13:33, Andre Oppermann wrote: > When a TCP connection via loopback back to localhost is made the whole > send, segmentation and receive path (with larger packets though) is still > executed. This has some considerable overhead. > > To short-circuit the send and receive sockets on localhost TCP connections > I've made a proof-of-concept patch that directly places the data in the > other side's socket buffer without doing any packetization and other protocol > overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, > ACK) and shutdown are still handled by normal TCP segments via loopback so > that firewalling stills works. The actual payload data during the session > won't be seen and the sequence numbers don't move other than for SYN and FIN. > The sequence are remain valid though. Obviously tcpdump won't see any data > transfers either if the connection has fused sockets. > > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable > operation and a rough doubling of the throughput on loopback connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should properly > defuse the sockets in all situations. > > Testers and feedback wanted: > > http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff > > -- > Andre > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AESNI driver and fpu_kern KPI
> >> >> - Unfortunately the driver in its current version can't be used with >> IPsec and with GELI where authentication is enabled. This is because >> the driver doesn't support sessions where both encryption and >> authentication is defined. Do you have plans to change it? >> I saw that you based crypto(9) bits on padlock, which does support >> sessions with authentication by calculating hashes in software. > My goal was to develop fpu_kern_enter() KPI. I used the AESNI as an > opportunity to test the KPI in real application. I may consider adding > software-implemented authentification sometime later. I would not object > if anybody do this instead of me. Today I've tested the patch with the same "issue" with IPsec, i've quickly re-included the same keyed hash function than padlock to test, tomorrow I will test again and I will post a patch if it works well. A minor things: aesni only compile as a module. Another idea for Sha1 would be to integrate the new version from intel http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1/ but it seems the 32bits version is not available at this time (and same licencing issue). Regards, Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Addition of lzma/xz compression to HEAD
Thanks, this is very useful. Fabien Le 11 mai 2010 à 21:31, Alexey Shuvaev a écrit : > Hello! > > Just FYI: noticed addition of lzma directory to BSD.include.dist mtree file. > Well, now it seems to work! > > /* Test file size 264 MiB */ > [wep4035] ~> ll /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > -rw-r--r-- 1 root wheel 277209600 Apr 20 20:58 > /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > > /* Cache file in memory */ > [wep4035] ~> cat /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > > /dev/null > > /* 30 seconds to gzip it */ > [wep4035] ~> time tar -cvzf 9-amd64.tar.tar.gz > /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 30.043u 0.541s 0:15.32 199.6% 37+2093k 0+747io 0pf+0w > > /* 64 seconds to bzip2 it */ > [wep4035] ~> time tar -cvjf 9-amd64.tar.tar.bz2 > /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 63.454u 0.686s 0:32.09 199.8% 37+2108k 0+650io 1pf+0w > > /* And 140 seconds to xz it */ > [wep4035] ~> time tar -cvJf 9-amd64.tar.tar.xz > /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 277.625u 0.857s 2:19.26 199.9% 37+2092k 0+432io 0pf+0w > > /* Resulting sizes : */ > [wep4035] ~> ll 9-amd64.tar.tar.* > -rw-r--r-- 1 lexx lexx 84830128 May 11 21:07 9-amd64.tar.tar.bz2 > -rw-r--r-- 1 lexx lexx 97667581 May 11 21:07 9-amd64.tar.tar.gz > -rw-r--r-- 1 lexx lexx 56366908 May 11 21:10 9-amd64.tar.tar.xz > > /* 3.5 seconds to gunzip the file (mostly IO-limited) */ > [wep4035] ~> cat 9-amd64.tar.tar.gz > /dev/null > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.gz > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 2.721u 0.747s 0:03.54 97.7% 42+2365k 3+2116io 0pf+0w > [wep4035] ~> rm -R usr/ > > /* 18 seconds to bunzip2 it */ > [wep4035] ~> cat 9-amd64.tar.tar.bz2 > /dev/null > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.bz2 > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 18.136u 0.999s 0:09.59 199.3% 37+2110k 1+2116io 0pf+0w > [wep4035] ~> rm -R usr/ > > /* And only 10 seconds to xzdec it */ > [wep4035] ~> cat 9-amd64.tar.tar.xz > /dev/null > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.xz > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 10.304u 0.771s 0:05.59 198.0% 38+2164k 3+2116io 0pf+0w > [wep4035] ~> rm -R usr/ > > > Thanks to all involved in bringing it to HEAD! > > Alexey. > > P.S. I'm not claiming any statistical validity of provided timings nor > that the testing procedure is correct. It is just to show that tar in HEAD > now works with lzma/xz compression. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ deadlock
fixed/works a lot better for me. > Applied and restarted portupgrade. > Will tell you tomorrow. > > Fabien > > Le 6 mai 2010 à 00:54, Jeff Roberson a écrit : > >> On Mon, 3 May 2010, Fabien Thomas wrote: >> >>>>> Hi Jeff, >>>>> >>>>> I'm with r207548 now and since some days i've system deadlock. >>>>> It seems related to SUJ with process waiting on suspfs or ppwait. >>>> >>>> I've also seen it stalled in suspfs, but this information is way better >>>> than what I was able to garner. I was only able to tell via ctrl-t on >>>> a stalled 'ls' process in a terminal before hard booting. >>>> >>>> Right now it occurs everytime I attempt to do the portmaster -a upgrade >>>> of X/KDE on this system. >>> >>> I've spotted this during multiple portupgrade -aR :) >> >> Can anyone who has experienced this hang test this patch: >> >> Thanks, >> Jeff >> >> Index: ffs_softdep.c >> === >> --- ffs_softdep.c (revision 207480) >> +++ ffs_softdep.c (working copy) >> @@ -9301,7 +9301,7 @@ >> hadchanges = 1; >> } >> /* Leave this inodeblock dirty until it's in the list. */ >> - if ((inodedep->id_state & (UNLINKED | DEPCOMPLETE)) == UNLINKED) >> + if ((inodedep->id_state & (UNLINKED | UNLINKONLIST)) == UNLINKED) >> hadchanges = 1; >> /* >>* If we had to rollback the inode allocation because of >> >> >>> >>> Fabien >>> ___ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >>> > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ deadlock
Applied and restarted portupgrade. Will tell you tomorrow. Fabien Le 6 mai 2010 à 00:54, Jeff Roberson a écrit : > On Mon, 3 May 2010, Fabien Thomas wrote: > >>>> Hi Jeff, >>>> >>>> I'm with r207548 now and since some days i've system deadlock. >>>> It seems related to SUJ with process waiting on suspfs or ppwait. >>> >>> I've also seen it stalled in suspfs, but this information is way better >>> than what I was able to garner. I was only able to tell via ctrl-t on >>> a stalled 'ls' process in a terminal before hard booting. >>> >>> Right now it occurs everytime I attempt to do the portmaster -a upgrade >>> of X/KDE on this system. >> >> I've spotted this during multiple portupgrade -aR :) > > Can anyone who has experienced this hang test this patch: > > Thanks, > Jeff > > Index: ffs_softdep.c > === > --- ffs_softdep.c (revision 207480) > +++ ffs_softdep.c (working copy) > @@ -9301,7 +9301,7 @@ >hadchanges = 1; >} >/* Leave this inodeblock dirty until it's in the list. */ > - if ((inodedep->id_state & (UNLINKED | DEPCOMPLETE)) == UNLINKED) > + if ((inodedep->id_state & (UNLINKED | UNLINKONLIST)) == UNLINKED) >hadchanges = 1; >/* > * If we had to rollback the inode allocation because of > > >> >> Fabien >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ deadlock
>> Hi Jeff, >> >> I'm with r207548 now and since some days i've system deadlock. >> It seems related to SUJ with process waiting on suspfs or ppwait. > > I've also seen it stalled in suspfs, but this information is way better > than what I was able to garner. I was only able to tell via ctrl-t on > a stalled 'ls' process in a terminal before hard booting. > > Right now it occurs everytime I attempt to do the portmaster -a upgrade > of X/KDE on this system. I've spotted this during multiple portupgrade -aR :) Fabien ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SUJ deadlock
Hi Jeff, I'm with r207548 now and since some days i've system deadlock. It seems related to SUJ with process waiting on suspfs or ppwait. The backtrace is the following: (kgdb) bt #0 sched_switch (td=0xc52d84c0, newtd=0xc4d88980, flags=260) at /usr/home/fabient/fabient-sandbox/sys/kern/sched_ule.c:1853 #1 0xc0a2838e in mi_switch (flags=260, newtd=0x0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:449 #2 0xc0a62a25 in sleepq_switch (wchan=0xc5389cf0, pri=159) at /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:530 #3 0xc0a62c6c in sleepq_wait (wchan=0xc5389cf0, pri=159) at /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:609 #4 0xc0a27aec in _sleep (ident=0xc5389cf0, lock=0xc5389ca8, priority=159, wmesg=0xc0f5c302 "suspfs", timo=0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:234 #5 0xc0ae2e62 in vn_start_write (vp=0xc66bdcc0, mpp=0xce79bb6c, flags=1) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:998 #6 0xc0ae1476 in vn_close (vp=0xc66bdcc0, flags=1, file_cred=0xc577f400, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:299 #7 0xc0ae2cc6 in vn_closefile (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:941 #8 0xc09d7e5e in fo_close (fp=0xc7bcd460, td=0xc52d84c0) at file.h:270 #9 0xc09d7ddc in _fdrop (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2348 #10 0xc09d775b in closef (fp=0xc7bcd460, td=0xc52d84c0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2117 #11 0xc09d526a in kern_close (td=0xc52d84c0, fd=3) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1162 #12 0xc09d50ea in close (td=0xc52d84c0, uap=0xce79bcf0) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1114 #13 0xc0e5816b in syscall (frame=0xce79bd38) at /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 #14 0xc0e302e0 in Xint0x80_syscall () at /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 If you need more information tell me. Fabien___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
m_getjcl and packet cache
Hi, I've posted on -net but in case people will have some feedback on this before commit. There is two solutions, let every driver get a test for MCLBYTES and call m_getcl (and then add support for at least igb, em, ixgbe) or integrate the fast path in m_getjcl. I've chosen to integrate the fast path in m_getjcl and patched the two case now redundant in the attached patch. From freebsd-net@: While doing some 10Gb benchmark i've found that m_getjcl does not benefit from the packet zone. There is a ~ 80% increase in FPS when applying the following patch. 256B frame driver to driver / stable_8: - 3 765 066 FPS - 6 868 153 FPS with the patch applied. Any advice ? Fabien patch-m_getjcl-packet Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
I've rev 207213 installed, i will update. > On Sun, 2 May 2010, Fabien Thomas wrote: > >> Hi Jeff, >> >> Before sending the 'bad' part i would like to say that it is very useful and >> save me a lot of time after a crash. >> >> I've updated the ports and there was no more space on the FS. >> It end up with this backtrace (After one reboot the kernel crashed a second >> time with the same backtrace): > > When did you update? I fixed a bug that looked just like this a day or two > ago. > > Thanks, > Jeff > >> >> (kgdb) bt >> #0 doadump () at >> /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:245 >> #1 0xc0a1a8fe in boot (howto=260) at >> /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:416 >> #2 0xc0a1ad4c in panic (fmt=Could not find the frame base for "panic". >> ) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:590 >> #3 0xc0d058b3 in remove_from_journal (wk=0xc4b4aa80) at >> /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:2204 >> #4 0xc0d07ebb in cancel_jaddref (jaddref=0xc4b4aa80, inodedep=0xc46bed00, >> wkhd=0xc46bed5c) >> at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3336 >> #5 0xc0d09401 in softdep_revert_mkdir (dp=0xc46ba6cc, ip=0xc4bba244) >> at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3898 >> #6 0xc0d37c49 in ufs_mkdir (ap=0xc8510b2c) at >> /usr/home/fabient/fabient-sandbox/sys/ufs/ufs/ufs_vnops.c:1973 >> #7 0xc0e7bc6e in VOP_MKDIR_APV (vop=0xc1085ea0, a=0xc8510b2c) at >> vnode_if.c:1534 >> #8 0xc0add64a in VOP_MKDIR (dvp=0xc485e990, vpp=0xc8510bec, cnp=0xc8510c00, >> vap=0xc8510b6c) at vnode_if.h:665 >> #9 0xc0add58f in kern_mkdirat (td=0xc4649720, fd=-100, path=0x804e9a0 >> , >> segflg=UIO_USERSPACE, mode=448) at >> /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3783 >> #10 0xc0add2fe in kern_mkdir (td=0xc4649720, path=0x804e9a0 > 0x804e9a0 out of bounds>, segflg=UIO_USERSPACE, mode=448) >> at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3727 >> #11 0xc0add289 in mkdir (td=0xc4649720, uap=0x0) at >> /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3706 >> #12 0xc0e5324b in syscall (frame=0xc8510d38) at >> /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 >> #13 0xc0e2b3c0 in Xint0x80_syscall () at >> /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 >> #14 0x0033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> >> Regards, >> Fabien >> >> >>> Hello, >>> >>> I fixed a few SUJ bugs. If those of you who reported one of the following >>> bugs could re-test I would greatly appreciate it. >>> >>> 1) panic on gnome start via softdep_cancel_link(). >>> 2) Difficulty setting flags on /. This can only be done from a direct >>> boot into single user but there were problems with tunefs that could lead >>> to the kernel and disk becoming out of sync with filesystem state. >>> 3) Kernel compiles without SOFTUPDATES defined in the config now work. >>> >>> I have had some reports of a hang waiting on journal space with certain >>> types of activity. I have only had this reported twice and I am not able >>> to reproduce no matter how much load I throw at the machine. If you >>> reproduce this please try to get a coredump or minidump. >>> >>> Thanks, >>> Jeff >>> ___ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Hi Jeff, Before sending the 'bad' part i would like to say that it is very useful and save me a lot of time after a crash. I've updated the ports and there was no more space on the FS. It end up with this backtrace (After one reboot the kernel crashed a second time with the same backtrace): (kgdb) bt #0 doadump () at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:245 #1 0xc0a1a8fe in boot (howto=260) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:416 #2 0xc0a1ad4c in panic (fmt=Could not find the frame base for "panic". ) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:590 #3 0xc0d058b3 in remove_from_journal (wk=0xc4b4aa80) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:2204 #4 0xc0d07ebb in cancel_jaddref (jaddref=0xc4b4aa80, inodedep=0xc46bed00, wkhd=0xc46bed5c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3336 #5 0xc0d09401 in softdep_revert_mkdir (dp=0xc46ba6cc, ip=0xc4bba244) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3898 #6 0xc0d37c49 in ufs_mkdir (ap=0xc8510b2c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ufs/ufs_vnops.c:1973 #7 0xc0e7bc6e in VOP_MKDIR_APV (vop=0xc1085ea0, a=0xc8510b2c) at vnode_if.c:1534 #8 0xc0add64a in VOP_MKDIR (dvp=0xc485e990, vpp=0xc8510bec, cnp=0xc8510c00, vap=0xc8510b6c) at vnode_if.h:665 #9 0xc0add58f in kern_mkdirat (td=0xc4649720, fd=-100, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3783 #10 0xc0add2fe in kern_mkdir (td=0xc4649720, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3727 #11 0xc0add289 in mkdir (td=0xc4649720, uap=0x0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3706 #12 0xc0e5324b in syscall (frame=0xc8510d38) at /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 #13 0xc0e2b3c0 in Xint0x80_syscall () at /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 #14 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Regards, Fabien > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the following > bugs could re-test I would greatly appreciate it. > > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct boot > into single user but there were problems with tunefs that could lead to the > kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. > > I have had some reports of a hang waiting on journal space with certain types > of activity. I have only had this reported twice and I am not able to > reproduce no matter how much load I throw at the machine. If you reproduce > this please try to get a coredump or minidump. > > Thanks, > Jeff > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
If you are on head/stable_7/stable_8 you can also do quick test with top mode pmcstat -S unhalted-cycles -T (http://wiki.freebsd.org/PmcTools/PmcTop). For more in depth post processing with source code (c+asm) you can output to Kcachegrind (http://wiki.freebsd.org/PmcTools/PmcKcachegrind). Fabien >> What's the traffic look like? Jumbo, standard, short frames? Any >> good ideas on profiling the code? I haven't figured out how to use >> the CPU TSC but there is a free running timer on the device that >> might be usable to calculate where the driver's time is spent. >> >> Dave > > In my experience hwpmc is the best and easiest way to profile anything > on FreeBSD. Here's something I sent to a different thread a couple of > months ago explaining how to use it: > > 1) If device hwpmc is not compiled into your kernel, kldload hwpmc(you > will need the HWPMC_HOOKS option in either case) > 2) Run pmcstat to begin taking samples(make sure that whatever you are > profiling is busy doing work first!): > > pmcstat -S unhalted-cycles -O /tmp/samples.out > > The -S option specifies what event you want to use to trigger > sampling. The unhalted-cycles is the best event to use if your > hardware supports it; pmc will take a sample every 64K non-idle CPU > cycles, which is basically equivalent to sampling based on time. If > the unhalted-cycles event is not supported by your hardware then the > instructions event will probably be the next best choice(although it's > nowhere near as good, as it will not be able to tell you, for example, > if a particular function is very expensive because it takes a lot of > cache misses compared to the rest of your program). One caveat with > the unhalted-cycles event is that time spent spinning on a spinlock or > adaptively spinning on a MTX_DEF mutex will not be counted by this > event, because most of the spinning time is spent executing an hlt > instruction that idles the CPU for a short period of time. > > Modern Intel and AMD CPUs offer a dizzying array of events. They're > mostly only useful if you suspect that a particular kind of event is > hurting your performance and you would like to know what is causing > those events. For example, if you suspect that data cache misses are > causing you problems you can take samples on cache misses. > Unfortunately on some of the newer CPUs(namely the Core2 family, > because that's what I'm doing most of my profiling on nowadays) I find > it difficult to figure out just what event to use to profile based on > cache misses. man pmc will give you an overview of pmc, and there are > manpages for every CPU family supported(eg man pmc.core2) > > 3) After you've run pmcstat for "long enough"(a proper definition of > long enough requires a statistician, which I most certainly am not, > but I find that for a busy system 10 seconds is enough), Control-C it > to stop it*. You can use pmcstat to post-process the samples into > human-readable text: > > pmcstat -R /tmp/samples.out -G /tmp/graph.txt > > The graph.txt file will show leaf functions on the left and their > callers beneath them, indented to reflect the callchain. It's not too > easy to describe and I don't have sample output available right now. > > > Another interesting tool for post-processing the samples is > pmcannotate. I've never actually used the tool before but it will > annotate the program's source to show which lines are the most > expensive. This of course needs unstripped modules to work. I think > that it will also work if the GNU "debug link" is in the stripped > module pointing to the location of the file with symbols. > > > * Here's a tip I picked up from Joseph Koshy's blog: to collect > samples for a fixed period of time(say 1 minute), have pmcstat run the > sleep command: > > pmcstat -S unhalted-cycles -O /tmp/samples.out sleep 60 > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
