slowdown caused by Linux kernel FD table implementation in fresh renderer

53 views
Skip to first unread message

Jann Horn

unread,
Aug 13, 2025, 4:52:34 PMAug 13
to loadi...@chromium.org
Hi!

I just sent a kinda-hacky CL for review that should remove some slowdown in fresh Linux renderers - see the CL description, basically on Linux there is a gnarly kernel slowpath that costs 10-50 milliseconds when the file descriptor table of a multithreaded process grows: https://chromium-review.googlesource.com/c/chromium/src/+/6845921

This seems to mainly happen on the ChildIOThread, sometimes also on the main thread. Mostly during initial page loads, but sometimes also during later interactions (like when hitting enter in Google Search).

I'm not really a Chrome developer, so idk if there's some kinda pinpoint test or such that should be run to quantify the performance impact.

Takashi Toyoshima

unread,
Aug 14, 2025, 2:33:45 AMAug 14
to Jann Horn, loadi...@chromium.org
We have perf try bots that can ensure the performance win for the uploaded Gerrit change.
https://source.chromium.org/chromium/chromium/src/+/main:docs/speed/perf_trybots.md

And, I think we still have some loading related benchmarks there though the sheet might be outdated.
https://docs.google.com/spreadsheets/d/1ZdQ9OHqEjF5v8dqNjd7lGUjJnK6sgi8MiqO7eZVMgD0/edit?usp=sharing

I tentatively kicked a job that compares performance before and after your CL, but I'm not sure this is the best benchmark for this improvement.
https://pinpoint-dot-chromeperf.appspot.com/job/17a8ba2b910000

Usually, we track the real-world impact via a Finch A/B testing as loading optimization is really challenging to be evaluated in benchmarks.
So, if you really want to track the impact, you may add a base::Feature flag with enabled by default setting, and run a finch with a server side configuration.


--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAG48ez10KY6Tc04XDw%2BsQCdHK-c%2BJCR0oWKt3Os7iR8%3D_0sHAA%40mail.gmail.com.


--
Takashi Toyoshima
Software Engineer, Google

Jann Horn

unread,
Aug 14, 2025, 10:22:51 AMAug 14
to Takashi Toyoshima, loadi...@chromium.org
On Thu, Aug 14, 2025, 08:33 Takashi Toyoshima <toyo...@chromium.org> wrote:
We have perf try bots that can ensure the performance win for the uploaded Gerrit change.
https://source.chromium.org/chromium/chromium/src/+/main:docs/speed/perf_trybots.md

And, I think we still have some loading related benchmarks there though the sheet might be outdated.
https://docs.google.com/spreadsheets/d/1ZdQ9OHqEjF5v8dqNjd7lGUjJnK6sgi8MiqO7eZVMgD0/edit?usp=sharing

I tentatively kicked a job that compares performance before and after your CL, but I'm not sure this is the best benchmark for this improvement.
https://pinpoint-dot-chromeperf.appspot.com/job/17a8ba2b910000

Sadly it looks like that doesn't build...

Usually, we track the real-world impact via a Finch A/B testing as loading optimization is really challenging to be evaluated in benchmarks.
So, if you really want to track the impact, you may add a base::Feature flag with enabled by default setting, and run a finch with a server side configuration.

Ah, I don't want to spend that much effort on this, it's just a single-line optimization.

Thanks for the information!
Reply all
Reply to author
Forward
0 new messages