/me saves a pointer to that mail to show to eager submitters who will
want to jump on this new thing.
On Mon, Jun 10, 2024 at 11:20:21AM -0700, Linus Torvalds wrote:
> So for example, if the code could possibly be a module, it's never
> going to be able to use runtime constants.
Perfectly fine with that.
> If the code doesn't show up as "noticeable percentage of kernel time
> on real loads", it will not be a valid use for runtime constants.
>
> The reason I did __d_lookup_rcu() is that I have optimized that
> function to hell and back before, and it *still* showed up at 14% of
> kernel time on my "empty kernel build" benchmark. And the constant
> load was a noticeable - but not dominant - part of that.
I have seen mails from you, off and on, about __d_lookup_rcu() :-P
> And yes, it shows up that high because it's all D$ misses, and the
> machine I tested on has more CPU cores than cache, so it's all kinds
> of broken. But the point ends up being that __d_lookup_rcu() is just
> very very hot on loads that just do a lot of 'stat()' calls (and such
> loads exist and aren't just microbenchmarks).
Yap.
> And yes, the benchmarks I run are odd ("why would anybody care about
> an empty kernel build?") but somewhat real to me (since I do builds
> between every pull even when they just change a couple of files).
You're not the only one - I'm building every patch too so yeah, got
a nice Threadripper for exactly that purpose too.
:-)
> And yes, to actually even see anything else than the CPU security
> issues on x86, you need to build without debug support, and without
> retpolines etc. So my profiles are "fake" in that sense, because they
> are the best case profiles without a lot of the horror that people
> enable.
Right, I run with the default settings because, well, we must eat our
own dogfood but yeah, all that zoo of config options to disable the
mitigations wasn't added just for fun so others will run similar
situtaions too, if they don't do that already.
> Others will have other real benchmarks, which is why I do think we'd
> end up with more uses of this. But I would expect a handful, not
> "hundreds".
That's a good rule. In talking to Peter I also didn't like the thing of
having a single ELF section per variable but if we're doing handful,
meh, ok, I guess.
> I could imagine some runtime constant in the core networking socket
> code, for example. Or in some scheduler thing. Or kernel entry code.
>
> But not ever in a driver or a filesystem, for example. Once you've
> gotten that far off the core code path, the "load a variable" overhead
> just isn't relevant any more.
Yeah, that makes sense.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
