From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8431 invoked by alias); 29 Oct 2009 17:27:47 -0000 Received: (qmail 8377 invoked by uid 48); 29 Oct 2009 17:27:32 -0000 Date: Thu, 29 Oct 2009 17:27:00 -0000 Message-ID: <20091029172732.8376.qmail@sourceware.org> From: "jkenisto at us dot ibm dot com" To: systemtap@sources.redhat.com In-Reply-To: <20091029165749.10869.jistone@redhat.com> References: <20091029165749.10869.jistone@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug kprobes/10869] kretprobes waste a lot of memory on kretprobe_instances X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00361.txt.bz2 ------- Additional Comments From jkenisto at us dot ibm dot com 2009-10-29 17:27 ------- Some historical perspective: We originally allocated all the instances for a particular kretprobe in a block. kmallocing the instances individually solved a problem we encountered when the kretprobe was unregistered while some instances were still active. We have to turn loose of the kretprobe object when the user unregisters it. One alternative is to treat the instances as a pool separate from their kretprobe -- in which case each instance would probably need a pointer to its pool as well as its rp pointer. (The rp pointer is promised by the API.) It might also be good to explore the (probably heretical) idea of allocating the instances (GFP_ATOMIC, since we can't block) only as needed. I also worked on a prototype where a group of kretprobes shared a common pool -- the idea being that of all the functions you're probing, only a limited set would be active at any one time. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10869 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.