On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
Why do you need to expedite the records through the ktrace at all ?
Wouldn't direct write(2)s to a file allow for better performance
due to not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system interface would be
prevented.
I believe that other usermode tracers also behave in the similar way,
using writes and not private kernel interface.
Also, what /proc issues did you mentioned ? There is
sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map
and does not require /proc mounted.
jemalloc:
https://github.com/alfredperlstein/jemalloc/compare/master...utrace2
Konstantin, you are right, it is a strange thing this utrace. I am not
sure why it was done this way.
You are correct in that much more efficient system could be made using
writes gathered into a single write(2).
Even without writes gathering, non-coalesced writes should be faster than
utrace.
Do you think there is any reason they may have re-used the kernel paths
for ktrace even at the cost of efficiency?
I can only speculate. The utracing of the malloc calls in the context
of the ktrace stream is useful for the human reading the trace. Instead
of seeing the sequence of unexplanaible calls allocating and freeing
memory, you would see something more penetrable. For example, you would
see accept/malloc/read/write/free, which could be usefully interpreted
as network server serving the client.
This context is not needed for a leak detector.
Now I may be wrong here, but I think it's an artifact of someone
noticing how useful fitting this into the ktrace system and leveraging
existing code.
Even though there are significant performance deficiencies, the actual
utility of the existing framework may have been such a stepping stool
towards tracing that it was just used.
Right now the code already exists, however it logs just {operation,
size, ptr}, example:
malloc, 512, -> 0xdeadbeef
free, 0, 0xdeadbeef
realloc, 512, 0 -> 0xdeadc0de
realloc, 1024, 0xdeadc0de -> 0xffff0000
free, 0, 0xffff0000
What do you think of just adding the address of the caller of
malloc/free/realloc to these already existing tracepoints?
-Alfred
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
