Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp3766609pxb; Mon, 27 Sep 2021 01:58:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydjYSJH9ZF/M8OijP6se1InVkj8rZRjmflZ30MnvH9e0tKLbrgryprltyluwd/P+mfqH8C X-Received: by 2002:aa7:d9d3:: with SMTP id v19mr21979057eds.131.1632733094934; Mon, 27 Sep 2021 01:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632733094; cv=none; d=google.com; s=arc-20160816; b=KMovVRWq+hqPC6jNV62Ultd21JcOown0PKyT9XDzb3bShH41lEQRtRHZDRfTVn6Cxw 3ecPZYKMr1zC3HU0l83bT3c2rhs//UWwigwMjganDKPkX0FT56j0XW4VR0iT4/+FkDFP PySWvnD9k4cDWF4IM3xkvS7y9U/idCIU6+gCkbw4HnhUW28nno5Mpvxf6MyT0Ndu1c1V my4UHwMJCRCJvWQzCvyXz+oalMhMW7iCEqya3SMTNidMK9lJ/O5gHhhFskY8fpfbJro2 SwB8SPoUYQKabzzx/blWfXDpL4QJSdPC8kaDTzSVirT2eJfa+LdVyC5wSQtm8BHf56ra oWfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=A3mvg3dUJwld6zU26voWMXz+U2zSsp8o/0tXwLQXJaU=; b=I4TNm2jZwVheVlzUl+U536TTRSEf9qPzCj4FVq2v9yRJg29N0i9GOQC6hFBTL61/XU DGVpSQoKjAPDgusCZuraVv6DgWkr1yj9PoLtgrS2mmoGhsU6Q+Sqp8cTM8EGRgb+xrSz 7k2aj6Uky+lJ8MLJ5S+BDD/HxK6/tlpautdCk3m55Pz/oIdB8H9lWdNIZJlL1obRcTvJ jWuWNOXti/9ns3Y5PrP4ZKsQRVwBOVysCc8jXBRPjv/00cTmL5lhflqfGjn2mTNaoO8A bvIAi+xZROVnvKpf3Z18YwsCmjKhfvL7ELNefSiFB5USiy8ltrvWMvKr14wO7jQHiS9Y gxHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UaCXWGRO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w18si2432437edx.77.2021.09.27.01.57.51; Mon, 27 Sep 2021 01:58:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UaCXWGRO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233558AbhI0I5g (ORCPT + 99 others); Mon, 27 Sep 2021 04:57:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:44976 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230439AbhI0I5f (ORCPT ); Mon, 27 Sep 2021 04:57:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id AEB7F610A2; Mon, 27 Sep 2021 08:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632732957; bh=nrxjUxZtkcxViJRTZLEt1C/yAc4qv3EH0uskY/IdXCg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UaCXWGROPjZ8fP0jsYOI0hmUwEFFtlPubWjS4ZTnTuvcMv/3K1rEKM8+6eG0T6ZUJ IZpVUAC4Q1ScrMKHG6xixMWtnPy/FPtDmnTlZC+GkD5qI6cg/W++1pBhjBfCtIIR76 L6tFdHP996CnwJTSPjDxShKDyQqiTqOx62nLEPS1oAu34UnU31IDSBUHty+gCckWVv F+lNLOf81eWZFvBE8zV7HmS0zk8WLt3xUisYKQ7pWQwEQdbI+8AxFjA5xGjkqQwam5 kRqLIWMdsq2pkcs+rtB8TgDdjJPU3y8xQNoAsbpewUzAFhPtU6Uba76tdLKezeoGC4 +hNViiMqfLhLg== Date: Mon, 27 Sep 2021 10:55:53 +0200 From: Mauro Carvalho Chehab To: Greg Kroah-Hartman Cc: Linux Doc Mailing List , linux-kernel@vger.kernel.org, Jonathan Corbet Subject: Re: [PATCH 0/8] (REBASED) get_abi.pl undefined: improve precision and performance Message-ID: <20210927105553.105f22c5@coco.lan> In-Reply-To: References: X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Thu, 23 Sep 2021 19:13:04 +0200 Greg Kroah-Hartman escreveu: > On Thu, Sep 23, 2021 at 05:41:11PM +0200, Mauro Carvalho Chehab wrote: > > Hi Greg, > > > > As requested, this is exactly the same changes, rebased on the top of > > driver-core/driver-core-next. > > > > - > > > > It follows a series of improvements for get_abi.pl. it is on the top of driver-core/driver-core-next. > > > > With such changes, on my development tree, the script is taking 6 seconds to run > > on my desktop: > > > > $ !1076 > > $ time ./scripts/get_abi.pl undefined |sort >undefined_after && cat undefined_after| perl -ne 'print "$1\n" if (m#.*/(\S+) not found#)'|sort|uniq -c|sort -nr >undefined_symbols; wc -l undefined_after undefined_symbols > > > > real 0m6,292s > > user 0m5,640s > > sys 0m0,634s > > 6838 undefined_after > > 808 undefined_symbols > > 7646 total > > > > And 7 seconds on a Dell Precision 5820: > > > > $ time ./scripts/get_abi.pl undefined |sort >undefined && cat undefined| perl -ne 'print "$1\n" if (m#.*/(\S+) not found#)'|sort|uniq -c|sort -nr >undefined_symbols; wc -l undefined; wc -l undefined_symbols > > > > real 0m7.162s > > user 0m5.836s > > sys 0m1.329s > > 6548 undefined > > 772 undefined_symbols > > > > Both tests were done against this tree (based on today's linux-next): > > > > $ https://git.kernel.org/pub/scm/linux/kernel/git/mchehab/devel.git/log/?h=get_abi_undefined-latest > > > > It should be noticed that, as my tree has several ABI fixes, the time to run the > > script is likely less than if you run on your tree, as there will be less symbols to > > be reported, and the algorithm is optimized to reduce the number of regexes > > when a symbol is found. > > > > Besides optimizing and improving the seek logic, this series also change the > > debug logic. It how receives a bitmap, where "8" means to print the regexes > > that will be used by "undefined" command: > > > > $ time ./scripts/get_abi.pl undefined --debug 8 >foo > > real 0m17,189s > > user 0m13,940s > > sys 0m2,404s > > > > $wc -l foo > > 18421939 foo > > > > $ cat foo > > ... > > /sys/kernel/kexec_crash_loaded =~ /^(?^:^/sys/.*/iio\:device.*/in_voltage.*_scale_available$)$/ > > /sys/kernel/kexec_crash_loaded =~ /^(?^:^/sys/.*/iio\:device.*/out_voltage.*_scale_available$)$/ > > /sys/kernel/kexec_crash_loaded =~ /^(?^:^/sys/.*/iio\:device.*/out_altvoltage.*_scale_available$)$/ > > /sys/kernel/kexec_crash_loaded =~ /^(?^:^/sys/.*/iio\:device.*/in_pressure.*_scale_available$)$/ > > ... > > > > On other words, on my desktop, the /sys match is performing >18M regular > > expression searches, which takes 6,2 seconds (or 17,2 seconds, if debug is > > enabled and sent to an area on my nvme storage). > > Better, it's down to 10 minutes on my machine now: > > real 10m39.218s > user 10m37.742s > sys 0m0.775s A lot better, but not clear why it is still taking ~40x more than here... It could well be due to the other ABI changes yet to be applied (I'll submit it probably later today), but it could also be related to something else. Could this be due to disk writes? Thanks, Mauro