From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 18:29:44 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 046F81D5; Thu, 10 Jan 2013 18:29:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E643CF0B; Thu, 10 Jan 2013 18:29:43 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 93D221A3E40; Thu, 10 Jan 2013 10:29:41 -0800 (PST) Message-ID: <50EF0892.104@mu.org> Date: Thu, 10 Jan 2013 13:29:38 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: malloc+utrace, tracking memory leaks in a running program. References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> <20130110073854.GQ2561@kib.kiev.ua> <50EEDB5E.2010906@mu.org> <20130110180514.GS2561@kib.kiev.ua> In-Reply-To: <20130110180514.GS2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:29:44 -0000 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