Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755377AbdC1LAE (ORCPT ); Tue, 28 Mar 2017 07:00:04 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:4802 "EHLO dggrg01-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1755324AbdC1LAD (ORCPT ); Tue, 28 Mar 2017 07:00:03 -0400 Message-ID: <58DA41EE.90607@huawei.com> Date: Tue, 28 Mar 2017 18:58:54 +0800 From: zhouchengming User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Miroslav Benes CC: , , , , , , Subject: Re: [PATCH] reduce the time of finding symbols for module References: <1490666535-19192-1-git-send-email-zhouchengming1@huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.236.183] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58DA420C.007B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7a8176cc95ba80b15a7cde5ab45bad02 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2190 Lines: 55 On 2017/3/28 17:00, Miroslav Benes wrote: > > Hi, > > On Tue, 28 Mar 2017, Zhou Chengming wrote: > >> It's reported that the time of insmoding a klp.ko for one of our >> out-tree modules is too long. >> >> ~ time sudo insmod klp.ko >> real 0m23.799s >> user 0m0.036s >> sys 0m21.256s > > Is this stable through several (>=10) runs? 23 seconds are really > suspicious. Yes, there is a linear search through all the kallsyms in > kallsyms_on_each_symbol(), but there are something like 70k symbols on my > machine (that is, way less than 1M). 23 seconds are somewhat unexpected. > Yes, it's stable through several runs. I think the big reason is that our out-tree module used a lot of static local variables. We can see '.rela.kpatch.dynrelas' contains many entries, so it will waste a lot of time if we use kallsyms_on_each_symbol() to find these symbols of module. Relocation section '.rela.kpatch.funcs' at offset 0x382e0 contains 3 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 003300000101 R_AARCH64_ABS64 0000000000000000 value_show + 0 000000000020 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 8 000000000028 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 0 Relocation section '.rela.kpatch.dynrelas' at offset 0x38328 contains 2562 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 003300000101 R_AARCH64_ABS64 0000000000000000 value_show + 14 000000000018 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 13 000000000020 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 0 000000000040 003300000101 R_AARCH64_ABS64 0000000000000000 value_show + 20 000000000058 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 13 000000000060 000b00000101 R_AARCH64_ABS64 0000000000000000 .kpatch.strings + 0 > If it is a problem, can we fix kallsyms_on_each_symbol() and replace the > linear search with something better? All users would benefit... > Yes, it's better if we can improve the linear search, but I can't think of that... Thanks. > Thanks, > Miroslav > > . >