From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32619 invoked by alias); 4 Mar 2014 01:54:55 -0000 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 Received: (qmail 32603 invoked by uid 89); 4 Mar 2014 01:54:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KHOP_BIG_TO_CC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail9.hitachi.co.jp Received: from mail9.hitachi.co.jp (HELO mail9.hitachi.co.jp) (133.145.228.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Mar 2014 01:54:50 +0000 Received: from mlsv7.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 46CE437C96; Tue, 4 Mar 2014 10:54:48 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv7.hitachi.co.jp (8.13.1/8.13.1) id s241smCb024983; Tue, 4 Mar 2014 10:54:48 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id s241skDR016864; Tue, 4 Mar 2014 10:54:47 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 62B90140046; Tue, 4 Mar 2014 10:54:46 +0900 (JST) Received: from [10.198.220.53] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 62413I9G9000084BC; Tue, 04 Mar 2014 10:54:45 +0900 Message-ID: <53153262.6080804@hitachi.com> Date: Tue, 04 Mar 2014 01:54:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andi Kleen Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Ananth N Mavinakayanahalli , Sandeepa Prabhu , Frederic Weisbecker , x86@kernel.org, Steven Rostedt , fche@redhat.com, mingo@redhat.com, systemtap@sourceware.org, "H. Peter Anvin" , Thomas Gleixner Subject: Re: [PATCH -tip v7 24/26] kprobes: Enlarge hash table to 4096 entries References: <20140227073315.20992.6174.stgit@ltc230.yrl.intra.hitachi.co.jp> <20140227073414.20992.16882.stgit@ltc230.yrl.intra.hitachi.co.jp> <87y50wut4j.fsf@tassilo.jf.intel.com> <530FBA99.3050504@hitachi.com> <53144C01.60106@hitachi.com> <20140303172050.GZ22728@two.firstfloor.org> In-Reply-To: <20140303172050.GZ22728@two.firstfloor.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q1/txt/msg00210.txt.bz2 (2014/03/04 2:20), Andi Kleen wrote: >> So, we can see the hash table larger than 2^9 (512 entries, >> which consumes 4KB) has no performance improvement. >> Would you think 4kB is still big for kprobes? :) > > 4KB should be fine. Thanks for evaluating. > Ah, I mistook. There are other tables(for kretprobes and locks) enlarged by this change too. To minimize the memory impact, I decided to decouple those tables, because the hash of the kretprobe tables are calculated by the task structure, whereas kprobe table's hash comes from the probed address. This means that the kretprobe has a different scalability issue, and should be solved by a different way. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com