[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53153262.6080804@hitachi.com>
Date: Tue, 04 Mar 2014 10:54:42 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Sandeepa Prabhu <sandeepa.prabhu@...aro.org>,
Frederic Weisbecker <fweisbec@...il.com>, x86@...nel.org,
Steven Rostedt <rostedt@...dmis.org>, fche@...hat.com,
mingo@...hat.com, systemtap@...rceware.org,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH -tip v7 24/26] kprobes: Enlarge hash table to 4096 entries
(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@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists