From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Mark Brown <mchehab+huawei@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Jani Nikula <jani.nikula@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Vegard Nossum <vegard.nossum@oracle.com>,
ksummit@lists.linux.dev,
Linux Documentation <linux-doc@vger.kernel.org>,
Akira Yokosawa <akiyks@gmail.com>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [TECH TOPIC] Kernel documentation - update and future directions
Date: Tue, 2 Sep 2025 16:42:01 +0200 [thread overview]
Message-ID: <xni5csulan6a3kngfw66okhrea2v2u4cwvfkk5vqy5p4xonowf@ajubzphgygit> (raw)
In-Reply-To: <8339a5dd-446d-4717-9d68-983f5e2354b3@sirena.org.uk>
On Tue, Sep 02, 2025 at 02:00:43PM +0100, Mark Brown wrote:
> On Tue, Sep 02, 2025 at 02:14:34PM +0200, Mauro Carvalho Chehab wrote:
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>
> > > > That takes about 90s for me.
>
> > > I wander why here is 3 times faster... disk cache? python version?
> > > faster ssd?
>
> > > What python version are you using?
>
> > Heh, after running twice or three times to avoid cache issues, I tested
> > running it on my machine with two different python versions:
>
> > $ time python3.13 scripts/kernel-doc.py . --none
>
> > real 0m31,660s
> > user 0m30,911s
> > sys 0m0,588s
>
> For me it's fairly consistent with python 3.11.2, I get some variation
> depending on what else is going on with the system but nothing hugely
> surprising. It should mostly be running from cache, the underlying disk
> is a reasonable SSD.
Yeah, it sounds that the huge performance increment was indeed on 3.11:
$ time python3.6 ./scripts/kernel-doc --none .
real 1m17,854s
user 1m16,651s
sys 0m0,707s
$ time python3.9 ./scripts/kernel-doc --none .
real 1m0,193s
user 0m58,942s
sys 0m0,614s
$ time python3.10 ./scripts/kernel-doc --none .
real 0m55,376s
user 0m54,168s
sys 0m0,636s
$ time python3.11 ./scripts/kernel-doc --none .
real 0m34,878s
user 0m33,665s
sys 0m0,661s
$ time python3.12 ./scripts/kernel-doc --none .
real 0m34,590s
user 0m33,844s
sys 0m0,613s
$ time python3.13 ./scripts/kernel-doc --none .
real 0m31,751s
user 0m30,951s
sys 0m0,640s
============== ============= ============= ================================
Python Version Real Time (s) User Time (s) Performance Increase (Real Time)
============== ============= ============= ================================
3.6 77.854 s 76.651 s (baseline)
3.9 60.193 s 58.942 s 22.7% faster
3.10 55.376 s 54.168 s 28.9% faster
3.11 34.878 s 33.665 s 55.2% faster
3.12 34.590 s 33.844 s 55.6% faster
3.13 31.751 s 30.951 s 59.2% faster
============== ============= ============= ================================
> The single core performance on this machine isn't
> amazing, it's more getting it's speed from having a bunch of cores.
As kernel-doc is currently single threaded, performance for a single
core is what matters most. I suspect that most of kernel-doc time is
spent handling regular expressions, specially when I/O is fast.
-
To sum-up those discussions, I can propose a patchset for the next
merge window that would:
1. change kernel-doc exec to re-run using the latest available python
version if version < 3.11, on a similar same way to what
scripts-pre-install and scripts-build-wrapper does(*);
2. add a command line parameter for kernel-doc to make it pick only
files that have a .. kernel-doc markup;
3. add a build logic to run it with make all, perhaps inside a Kconfig
symbol like "config DOC_WARNINGS", disabled by default, but enabled
with allyesconfig/allmodconfig.
4. with time, add more validations there, like checking for
EXPORT_SYMBOL without documentation and other neat features.
This needs to be coordinated with some efforts to cleanup warnings,
to avoid having hundreds of new warnings at build time.
This way, even on LTS, we'll have fast kernel-doc check, and will likely
take lot less than 32 seconds, as it will only validate a small set of
files that are pointed by a kernel-doc markup notation inside
Documentation, specially if Python >= 3.11 is installed.
It should be noticed that can generate out of blue lots of new
warnings that are currently there by currently hidden, specially
if we add "-Wall" to the build target.
Comments?
(*) The logic there checks if python version is below a minimal
version. If it is, it seeks for python 3.x exec files, picking
the latest one if found, and re-running it with such version.
--
Thanks,
Mauro
next prev parent reply other threads:[~2025-09-02 14:42 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 22:55 Jonathan Corbet
2025-08-25 10:35 ` Mauro Carvalho Chehab
2025-08-28 23:01 ` Laurent Pinchart
2025-08-30 13:37 ` Jonathan Corbet
2025-08-30 16:00 ` Vegard Nossum
2025-08-30 22:23 ` Laurent Pinchart
2025-08-30 23:08 ` Jonathan Corbet
2025-08-31 14:03 ` Mauro Carvalho Chehab
2025-08-31 20:16 ` Jonathan Corbet
2025-09-01 6:17 ` Randy Dunlap
2025-09-01 19:27 ` Mauro Carvalho Chehab
2025-09-01 10:09 ` Jani Nikula
2025-09-01 16:51 ` Randy Dunlap
2025-09-01 17:52 ` Mark Brown
2025-09-01 18:15 ` Randy Dunlap
2025-09-01 18:20 ` Mark Brown
2025-09-01 18:25 ` Jonathan Corbet
2025-09-01 18:40 ` Mark Brown
2025-09-01 19:51 ` Jonathan Corbet
2025-09-01 22:52 ` Mauro Carvalho Chehab
2025-09-01 18:46 ` Mauro Carvalho Chehab
2025-09-01 18:52 ` Mark Brown
2025-09-01 22:56 ` Mauro Carvalho Chehab
2025-09-02 11:15 ` Mark Brown
2025-09-02 11:59 ` Mauro Carvalho Chehab
2025-09-02 12:14 ` Mauro Carvalho Chehab
2025-09-02 13:00 ` Mark Brown
2025-09-02 14:42 ` Mauro Carvalho Chehab [this message]
2025-09-02 15:15 ` Jonathan Corbet
2025-09-02 17:19 ` Mauro Carvalho Chehab
2025-09-02 18:52 ` Laurent Pinchart
2025-09-03 7:47 ` Jani Nikula
2025-09-03 10:04 ` Mauro Carvalho Chehab
2025-09-03 10:25 ` Jani Nikula
2025-09-02 18:58 ` Jonathan Corbet
2025-09-02 22:35 ` Mauro Carvalho Chehab
2025-09-03 6:29 ` Johannes Berg
2025-09-03 10:42 ` Mauro Carvalho Chehab
2025-09-03 10:45 ` Johannes Berg
2025-09-03 10:54 ` Johannes Berg
2025-09-03 14:57 ` Mauro Carvalho Chehab
2025-09-03 15:07 ` Laurent Pinchart
2025-09-03 15:17 ` Konstantin Ryabitsev
2025-09-03 15:22 ` Miguel Ojeda
2025-09-03 15:11 ` Johannes Berg
2025-09-03 15:25 ` Mauro Carvalho Chehab
2025-09-03 15:37 ` Jonathan Corbet
2025-09-03 15:52 ` Mauro Carvalho Chehab
2025-09-03 13:39 ` Mauro Carvalho Chehab
2025-09-03 13:51 ` Laurent Pinchart
2025-09-01 19:53 ` Jonathan Corbet
2025-09-01 23:15 ` Mauro Carvalho Chehab
2025-09-01 18:37 ` Mauro Carvalho Chehab
2025-09-01 19:05 ` Andrew Lunn
2025-09-01 19:17 ` Mark Brown
2025-09-02 10:42 ` Jani Nikula
2025-09-02 11:55 ` Mauro Carvalho Chehab
2025-09-02 12:07 ` Jani Nikula
2025-09-02 15:07 ` Mauro Carvalho Chehab
2025-09-01 18:26 ` Mauro Carvalho Chehab
2025-09-02 10:55 ` Jani Nikula
2025-09-02 12:04 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xni5csulan6a3kngfw66okhrea2v2u4cwvfkk5vqy5p4xonowf@ajubzphgygit \
--to=mchehab+huawei@kernel.org \
--cc=akiyks@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=vegard.nossum@oracle.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox