From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C47FC433FE for ; Wed, 26 Oct 2022 19:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234840AbiJZTG6 (ORCPT ); Wed, 26 Oct 2022 15:06:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234528AbiJZTGh (ORCPT ); Wed, 26 Oct 2022 15:06:37 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 113AF141383; Wed, 26 Oct 2022 12:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=r3Pfzq8iLf21/gz3vKU7KH69j7rAkB4oAHyVkIHhiQY=; b=xF+2rcJB7udh+J+Ag+JT79VckR 5/aeywQviRtPSnZ1ya9NT5lSAPGHHA9rhIJHo+Mt4EvVqNvp16GSByh4l3YA9wr8mnJzJlGr0jCNb uc39VCS4doPpfNlfEzYYzd4AJkxMzm2sl++QAN6ALwLoz4CuzlvQH4V9bO9UxEPW/Mha+7kDNixxS aIPz0NPwzTOrk56hw0Un20+nzgGcVR3U7I5bS7KX7GDsvt+tKFrYomWjZehL+775+fzIPKyCRurCd l8ddecgsWb6qqaZy2vUq7BcVpJtQHOeWC3pdyvillVYqjLFfj8sFJnT2gwkfY8rwDK6pv0ikz65Js jjZd+1yQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1onlge-00Aer3-5w; Wed, 26 Oct 2022 19:03:36 +0000 Date: Wed, 26 Oct 2022 12:03:36 -0700 From: Luis Chamberlain To: "Leizhen (ThunderTown)" Cc: Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Masahiro Yamada , Alexei Starovoitov , Jiri Olsa , Kees Cook , Andrew Morton , linux-modules@vger.kernel.org, Steven Rostedt , Ingo Molnar Subject: Re: [PATCH v7 00/11] kallsyms: Optimizes the performance of lookup symbols Message-ID: References: <20221017064950.2038-1-thunder.leizhen@huawei.com> <77f1c8f0-5e67-0e57-9285-15ba613044fb@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77f1c8f0-5e67-0e57-9285-15ba613044fb@huawei.com> Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 26, 2022 at 02:44:36PM +0800, Leizhen (ThunderTown) wrote: > On 2022/10/26 1:53, Luis Chamberlain wrote: > > This answers how we don't use a hash table, the question was *should* we > > use one? > > I'm not the original author, and I can only answer now based on my understanding. Maybe > the original author didn't think of the hash method, or he has weighed it out. > > Hash is a good solution if only performance is required and memory overhead is not > considered. Using hash will increase the memory size by up to "4 * kallsyms_num_syms + > 4 * ARRAY_SIZE(hashtable)" bytes, kallsyms_num_syms is about 1-2 million. > > Because I don't know what hash algorithm will be used, the cost of generating the > hash value corresponding to the symbol name is unknown now. But I think it's gonna > be small. But it definitely needs a simpler algorithm, the tool needs to implement > the same hash algorithm. For instance, you can look at evaluating if alloc_large_system_hash() would help. Luis