| Author |
Message |
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
 Posted: Sun Mar 31, 2002 8:12 pm Post subject:
Re: mutex profiling
|
|
|
With the footnote that the TSC's are not synchronized on SMP
systems, this looks like a nice initial tool to get some kind
of picture of the locking situation in the kernel.
Poul-Henning
In message <xzp8z88e6i1.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
| Quote: | --=-=-=
The attached patch (derived from patches by Eivind) adds code to
record statistics about MTX_DEF locks. It's currently i386-only as it
uses the TSC to measure the amount of time each mutex is held. Once
|
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Greg 'groggy' Lehey
*nix forums beginner
Joined: 31 Mar 2002
Posts: 1
|
| Posted: Sun Mar 31, 2002 11:40 pm Post subject:
Re: mutex profiling
|
|
|
On Monday, 1 April 2002 at 0:07:18 +0200, Dag-Erling Smorgrav wrote:
| Quote: | The attached patch (derived from patches by Eivind) adds code to
record statistics about MTX_DEF locks. It's currently i386-only as it
uses the TSC to measure the amount of time each mutex is held. Once
compiled in and enabled, statistics can be retrieved using sysctl( .
The code records four numbers for each mutex (longest time held in one
go, total time held, number of acquisitions, average time held) and
returns a top-16 list for each. Each mutex is identified by the place
where it was first acquired, so multiple instances of the same type of
mutex (e.g. proc lock, filedesc lock) are counted as one. Here's a
sample listing (with some annotations):
|
Excellent!
Of course, it could be better :-)
It would be nice to get a list by lock of each of the four parameters,
something like:
max total count average
i386/i386/machdep.c:1715 10653798 5472784414 1127992 4852
(repeat for each lock)
One of the things that I can't recall anybody looking at has been
whether to spin or block on each kind of lock. This information would
help make that decision. What units are the times in? If the average
time spent in Giant is 4852 µs, I'd say it's definitely a waste of
time to spin on it at all. If it's 4852 ns, it's probably the correct
thing to do.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 01, 2002 9:38 am Post subject:
Re: mutex profiling
|
|
|
Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
| Quote: | With the footnote that the TSC's are not synchronized on SMP
systems [...]
|
We tried using {,get}nanouptime() instead, but got nothing but
zeroes...
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 01, 2002 9:41 am Post subject:
Re: mutex profiling
|
|
|
Greg 'groggy' Lehey <grog@FreeBSD.org> writes:
| Quote: | It would be nice to get a list by lock of each of the four parameters,
something like:
max total count average
i386/i386/machdep.c:1715 10653798 5472784414 1127992 4852
(repeat for each lock)
|
Good idea, I'll add that.
| Quote: | One of the things that I can't recall anybody looking at has been
whether to spin or block on each kind of lock. This information would
help make that decision. What units are the times in?
|
Clock cycles.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Mon Apr 01, 2002 10:28 am Post subject:
Re: mutex profiling
|
|
|
In message <xzp4rivejja.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
| Quote: | Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
With the footnote that the TSC's are not synchronized on SMP
systems [...]
We tried using {,get}nanouptime() instead, but got nothing but
zeroes...
|
nanouptime() should not get you zeros, but it would be slower than
TSC. getnanouptime would hopefully give you all zeros.
I didn't mean to imply that the TSC was wrong as such, but merely
wanted to point to the fact that a mutex locked on one CPU and
unlocked on another will (likely) screw up your numbers big time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 01, 2002 2:10 pm Post subject:
Re: mutex profiling
|
|
|
Greg 'groggy' Lehey <grog@FreeBSD.org> writes:
| Quote: | It would be nice to get a list by lock of each of the four parameters,
something like:
max total count average
i386/i386/machdep.c:1715 10653798 5472784414 1127992 4852
(repeat for each lock)
|
How's this?
des@des ~% sysctl -n debug.mutex.prof.all
mutex max total count
kern/kern_fork.c:467 6124730 162187907 986568
i386/i386/machdep.c:1715 10024515 2426296920 620041
kern/vfs_syscalls.c:1692 12998 118467144 281628
kern/kern_descrip.c:748 87515 196871456 238729
kern/vfs_vnops.c:762 12361 8096945 24015
vm/uma_core.c:1179 441720 98833757 392171
kern/kern_sx.c:147 8604 19467888 98071
kern/kern_lock.c:227 13992 228025483 520510
fs/pseudofs/pseudofs_vncache.c:211 862 109653 208
kern/kern_prot.c:1706 9726 13211102 43701
kern/vfs_subr.c:1788 10696 16134536 80109
kern/imgact_elf.c:518 11827 1793896 3801
vm/vm_object.c:599 1078 561152 2956
kern/kern_sx.c:102 12378 15707316 29498
kern/kern_resource.c:900 7723 3815878 18642
kern/kern_proc.c:356 7798 605512 365
kern/kern_proc.c:972 727 145459 633
kern/vfs_subr.c:1857 12330 88298631 231204
sys/buf.h:278 8950 10131632 34047
kern/tty.c:1053 2071 75200 198
kern/sys_pipe.c:450 6780 1395976 1410
kern/vfs_subr.c:1805 9496 22600436 54091
kern/vfs_subr.c:782 6202 3523460 17028
kern/vfs_subr.c:2356 761 55381 269
vm/uma_core.c:1701 11202 1714480 1340
kern/vfs_lookup.c:149 20364 13832882 21443
ufs/ufs/ufs_dirhash.c:356 7669 1787405 1333
ufs/ufs/ufs_ihash.c:110 9396 8938672 17295
ufs/ffs/ffs_vfsops.c:1172 10552 642025 4200
kern/kern_lock.c:507 822 704605 4247
kern/vfs_subr.c:936 401354 3583794 2351
ufs/ufs/ufs_dirhash.c:158 1568 381173 701
vm/uma_core.c:1301 39491 1624803 1042
kern/kern_prot.c:1757 7278 1157954 4514
vm/swap_pager.c:306 12060 3043719 1512
kern/vfs_subr.c:1739 6767 463008 1251
kern/sys_pipe.c:229 7250 5170251 10120
kern/sys_pipe.c:259 5853 4140334 26902
vm/uma_core.c:1678 2403 82426 79
kern/subr_eventhandler.c:78 1605 49847 46
kern/kern_descrip.c:1108 21367 7456128 4962
pci/if_xl.c:1259 945556 3979999 84
kern/subr_mbuf.c:452 6244 3756251 13490
kern/subr_mbuf.c:577 2837 11077 59
net/bpf.c:1268 695 854 2
net/bpf.c:627 6557 97926 59
net/bpf.c:254 7413 147862 46
net/if_var.h:294 3298 36665 140
kern/sys_generic.c:800 20769 31401570 87233
kern/vfs_subr.c:419 1758 94701 84
vm/uma_core.c:1761 17668 671222 167
ufs/ufs/ufs_vnops.c:298 5371 537428 786
ufs/ufs/ufs_ihash.c:114 6323 250572 253
dev/random/yarrow.c:265 255551 4751740 63
kern/kern_prot.c:1910 3961 21217 49
kern/sys_pipe.c:1179 5596 1660837 1315
kern/tty_tty.c:89 2645 5455 6
kern/kern_exit.c:285 3916 29487 16
kern/sys_pipe.c:843 5238 168056 120
kern/sys_pipe.c:1129 3111 22629 19
kern/kern_resource.c:864 2124 95751 77
kern/sys_pipe.c:1302 6326 13639 5
kern/kern_proc.c:372 9044 42850 29
kern/kern_descrip.c:1577 3511 3511 1
kern/kern_fork.c:562 2172 27768 39
kern/init_main.c:495 2527 82565 108
vm/uma_core.c:1887 3835 42494 48
vm/uma_core.c:232 727662 876974 154
vm/uma_core.c:1716 679 3261 5
vm/uma_core.c:985 113894 534906 5
vm/device_pager.c:156 3001 5445 19
vm/swap_pager.c:1694 3306 56747 138
kern/kern_descrip.c:168 13772 47793 25
ufs/ufs/ufs_dirhash.c:495 4150 132187 97
kern/kern_fork.c:535 27527 59469 12
dev/sound/pcm/channel.c:677 12177241 23561042 8
dev/sound/pcm/sound.c:134 65432 173901 21
kern/kern_descrip.c:264 12207 1311316 9670
(I didn't include average since it can be computed from total and
count)
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Mon Apr 01, 2002 2:26 pm Post subject:
Re: mutex profiling
|
|
|
In message <xzplmc72ydd.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
| Quote: | How's this?
des@des ~% sysctl -n debug.mutex.prof.all
mutex max total count
kern/kern_fork.c:467 6124730 162187907 986568
i386/i386/machdep.c:1715 10024515 2426296920 620041
kern/vfs_syscalls.c:1692 12998 118467144 281628
(I didn't include average since it can be computed from total and
count)
|
<BIKESHED>
I would include the average so that people can do
sysctl -n debug.mutex.prof.all | sort +4rn
</BIKESHED>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 01, 2002 2:31 pm Post subject:
Re: mutex profiling
|
|
|
"Andrew R. Reiter" <arr@FreeBSD.org> writes:
| Quote: | Can we perhaps have the ability to dump the lock char * description? Or
are you doing this way b/c you can get the file and line #'s? Looks good,
tho.
|
I can get both; I'm doing it this way because Eivind did it this way
and it didn't occur to me to change it. Is one preferrable to the
other?
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 01, 2002 2:32 pm Post subject:
Re: mutex profiling
|
|
|
Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
| Quote: | BIKESHED
I would include the average so that people can do
sysctl -n debug.mutex.prof.all | sort +4rn
/BIKESHED
|
True; then we wouldn't need the four other sysctls at all...
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Eivind Eklund
*nix forums beginner
Joined: 01 Apr 2002
Posts: 23
|
| Posted: Mon Apr 01, 2002 2:41 pm Post subject:
Re: mutex profiling
|
|
|
On Mon, Apr 01, 2002 at 06:31:31PM +0200, Dag-Erling Smorgrav wrote:
| Quote: | "Andrew R. Reiter" <arr@FreeBSD.org> writes:
Can we perhaps have the ability to dump the lock char * description? Or
are you doing this way b/c you can get the file and line #'s? Looks good,
tho.
I can get both; I'm doing it this way because Eivind did it this way
and it didn't occur to me to change it. Is one preferrable to the
other?
|
The use of filename/line combinations was done to be able to find what actual
lock aquisitions result in introduction of large amounts of latency. The
basic reason I wrote this patch was to be able to find what parts of our code
result in latency, to focus effort there.
Measuring the lock types themselves (which is what the lock description would
give you) give a much less granular set of information. This accumulation can
(non-trivially) be done separately, but if you do the accumulation, it is not
possible to recover the information about where the latency is introduced.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Mon Apr 01, 2002 2:47 pm Post subject:
Re: mutex profiling
|
|
|
In message <20020401184158.A15491@phoenix.dmnshq.net>, Eivind Eklund writes:
| Quote: | On Mon, Apr 01, 2002 at 06:31:31PM +0200, Dag-Erling Smorgrav wrote:
"Andrew R. Reiter" <arr@FreeBSD.org> writes:
Can we perhaps have the ability to dump the lock char * description? Or
are you doing this way b/c you can get the file and line #'s? Looks good,
tho.
I can get both; I'm doing it this way because Eivind did it this way
and it didn't occur to me to change it. Is one preferrable to the
other?
The use of filename/line combinations was done to be able to find what actual
lock aquisitions result in introduction of large amounts of latency. The
basic reason I wrote this patch was to be able to find what parts of our code
result in latency, to focus effort there.
Measuring the lock types themselves (which is what the lock description would
give you) give a much less granular set of information. This accumulation can
(non-trivially) be done separately, but if you do the accumulation, it is not
possible to recover the information about where the latency is introduced.
|
I think you misunderstood, I think the request was to get the lock
name in addition to the file/line info.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Eivind Eklund
*nix forums beginner
Joined: 01 Apr 2002
Posts: 23
|
| Posted: Mon Apr 01, 2002 3:03 pm Post subject:
Re: mutex profiling
|
|
|
On Mon, Apr 01, 2002 at 06:47:24PM +0200, Poul-Henning Kamp wrote:
| Quote: | In message <20020401184158.A15491@phoenix.dmnshq.net>, Eivind Eklund writes:
The use of filename/line combinations was done to be able to find what actual
lock aquisitions result in introduction of large amounts of latency. The
basic reason I wrote this patch was to be able to find what parts of our code
result in latency, to focus effort there.
Measuring the lock types themselves (which is what the lock description would
give you) give a much less granular set of information. This accumulation can
(non-trivially) be done separately, but if you do the accumulation, it is not
possible to recover the information about where the latency is introduced.
I think you misunderstood, I think the request was to get the lock
name in addition to the file/line info.
|
My intent was just to give the background for the choice, as DES is the one
presently working on the patch.
Apart from that, it would probably be useful to be able to aquire statisticks
for locks based on either of those keys. The filename/line combination gives
single lock aquisitions, and show where we get latency from that, and thus
which code paths would give us the largest amount of latency reduction by
being shortened (or broken by a lock release/reaquire, the way to Linux low
latency patches do it). I suspect statistics based on lock types
(descriptions) will give us ideas of what introduce overall system latency and
for what types of locks we should be doing more work to optimize overall
throughput.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jake Burkholder
*nix forums beginner
Joined: 27 Mar 2002
Posts: 12
|
| Posted: Mon Apr 01, 2002 3:05 pm Post subject:
Re: mutex profiling
|
|
|
Apparently, On Mon, Apr 01, 2002 at 12:07:18AM +0200,
Dag-Erling Smorgrav said words to the effect of;
| Quote: | The attached patch (derived from patches by Eivind) adds code to
record statistics about MTX_DEF locks. It's currently i386-only as it
uses the TSC to measure the amount of time each mutex is held. Once
|
You can use the get_cyclecount() function as an MI way to read the tsc
or whatever cheap cyclecounter an architecture provides. I think everything
we run on but i386 and i486 have one.
Jake
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Andrew R. Reiter
*nix forums beginner
Joined: 01 Apr 2002
Posts: 11
|
| Posted: Mon Apr 01, 2002 4:23 pm Post subject:
Re: mutex profiling
|
|
|
On 1 Apr 2002, Dag-Erling Smorgrav wrote:
:Greg 'groggy' Lehey <grog@FreeBSD.org> writes:
:> It would be nice to get a list by lock of each of the four parameters,
:> something like:
:>
:> max total count average
:> i386/i386/machdep.c:1715 10653798 5472784414 1127992 4852
:> (repeat for each lock)
:
:How's this?
Can we perhaps have the ability to dump the lock char * description? Or
are you doing this way b/c you can get the file and line #'s? Looks good,
tho.
Cheers,
Andrew
:
:des@des ~% sysctl -n debug.mutex.prof.all
:mutex max total count
:kern/kern_fork.c:467 6124730 162187907 986568
:i386/i386/machdep.c:1715 10024515 2426296920 620041
:kern/vfs_syscalls.c:1692 12998 118467144 281628
:kern/kern_descrip.c:748 87515 196871456 238729
:kern/vfs_vnops.c:762 12361 8096945 24015
:vm/uma_core.c:1179 441720 98833757 392171
:kern/kern_sx.c:147 8604 19467888 98071
:kern/kern_lock.c:227 13992 228025483 520510
:fs/pseudofs/pseudofs_vncache.c:211 862 109653 208
:kern/kern_prot.c:1706 9726 13211102 43701
:kern/vfs_subr.c:1788 10696 16134536 80109
:kern/imgact_elf.c:518 11827 1793896 3801
:vm/vm_object.c:599 1078 561152 2956
:kern/kern_sx.c:102 12378 15707316 29498
:kern/kern_resource.c:900 7723 3815878 18642
:kern/kern_proc.c:356 7798 605512 365
:kern/kern_proc.c:972 727 145459 633
:kern/vfs_subr.c:1857 12330 88298631 231204
:sys/buf.h:278 8950 10131632 34047
:kern/tty.c:1053 2071 75200 198
:kern/sys_pipe.c:450 6780 1395976 1410
:kern/vfs_subr.c:1805 9496 22600436 54091
:kern/vfs_subr.c:782 6202 3523460 17028
:kern/vfs_subr.c:2356 761 55381 269
:vm/uma_core.c:1701 11202 1714480 1340
:kern/vfs_lookup.c:149 20364 13832882 21443
:ufs/ufs/ufs_dirhash.c:356 7669 1787405 1333
:ufs/ufs/ufs_ihash.c:110 9396 8938672 17295
:ufs/ffs/ffs_vfsops.c:1172 10552 642025 4200
:kern/kern_lock.c:507 822 704605 4247
:kern/vfs_subr.c:936 401354 3583794 2351
:ufs/ufs/ufs_dirhash.c:158 1568 381173 701
:vm/uma_core.c:1301 39491 1624803 1042
:kern/kern_prot.c:1757 7278 1157954 4514
:vm/swap_pager.c:306 12060 3043719 1512
:kern/vfs_subr.c:1739 6767 463008 1251
:kern/sys_pipe.c:229 7250 5170251 10120
:kern/sys_pipe.c:259 5853 4140334 26902
:vm/uma_core.c:1678 2403 82426 79
:kern/subr_eventhandler.c:78 1605 49847 46
:kern/kern_descrip.c:1108 21367 7456128 4962
:pci/if_xl.c:1259 945556 3979999 84
:kern/subr_mbuf.c:452 6244 3756251 13490
:kern/subr_mbuf.c:577 2837 11077 59
:net/bpf.c:1268 695 854 2
:net/bpf.c:627 6557 97926 59
:net/bpf.c:254 7413 147862 46
:net/if_var.h:294 3298 36665 140
:kern/sys_generic.c:800 20769 31401570 87233
:kern/vfs_subr.c:419 1758 94701 84
:vm/uma_core.c:1761 17668 671222 167
:ufs/ufs/ufs_vnops.c:298 5371 537428 786
:ufs/ufs/ufs_ihash.c:114 6323 250572 253
:dev/random/yarrow.c:265 255551 4751740 63
:kern/kern_prot.c:1910 3961 21217 49
:kern/sys_pipe.c:1179 5596 1660837 1315
:kern/tty_tty.c:89 2645 5455 6
:kern/kern_exit.c:285 3916 29487 16
:kern/sys_pipe.c:843 5238 168056 120
:kern/sys_pipe.c:1129 3111 22629 19
:kern/kern_resource.c:864 2124 95751 77
:kern/sys_pipe.c:1302 6326 13639 5
:kern/kern_proc.c:372 9044 42850 29
:kern/kern_descrip.c:1577 3511 3511 1
:kern/kern_fork.c:562 2172 27768 39
:kern/init_main.c:495 2527 82565 108
:vm/uma_core.c:1887 3835 42494 48
:vm/uma_core.c:232 727662 876974 154
:vm/uma_core.c:1716 679 3261 5
:vm/uma_core.c:985 113894 534906 5
:vm/device_pager.c:156 3001 5445 19
:vm/swap_pager.c:1694 3306 56747 138
:kern/kern_descrip.c:168 13772 47793 25
:ufs/ufs/ufs_dirhash.c:495 4150 132187 97
:kern/kern_fork.c:535 27527 59469 12
:dev/sound/pcm/channel.c:677 12177241 23561042 8
:dev/sound/pcm/sound.c:134 65432 173901 21
:kern/kern_descrip.c:264 12207 1311316 9670
:
 I didn't include average since it can be computed from total and
:count)
:
:DES
:--
:Dag-Erling Smorgrav - des@ofug.org
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-arch" in the body of the message
:
--
Andrew R. Reiter
arr@watson.org
arr@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Andrew R. Reiter
*nix forums beginner
Joined: 01 Apr 2002
Posts: 11
|
| Posted: Mon Apr 01, 2002 4:35 pm Post subject:
Re: mutex profiling
|
|
|
On 1 Apr 2002, Dag-Erling Smorgrav wrote:
:"Andrew R. Reiter" <arr@FreeBSD.org> writes:
:> Can we perhaps have the ability to dump the lock char * description? Or
:> are you doing this way b/c you can get the file and line #'s? Looks good,
:> tho.
:
:I can get both; I'm doing it this way because Eivind did it this way
:and it didn't occur to me to change it. Is one preferrable to the
:other?
:
Well, I guess that the file and line number is of more use than lock name,
especially for what we want to use this information for. If others find
that information more helpful, then perhaps we should think about it
further, otherwise, I think what you and Eivind have worked up should be
useful. Thanks.
Cheers,
Andrew
--
Andrew R. Reiter
arr@watson.org
arr@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
