Messages in this thread | | | From | Mateusz Guzik <> | Date | Fri, 3 Mar 2023 20:37:02 +0100 | Subject | Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible |
| |
On 3/3/23, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Mar 3, 2023 at 9:39 AM Mateusz Guzik <mjguzik@gmail.com> wrote: >> >> So the key is: memset is underperforming at least on x86-64 for >> certain sizes and the init-on-alloc thingy makes it used significantly >> more, exacerbating the problem > > One reason that the kernel memset isn't as optimized as memcpy, is > simply because under normal circumstances it shouldn't be *used* that > much outside of page clearing and constant-sized structure > initialization. >
I mentioned in the previous e-mail that memset is used a lot even without the problematic opt and even have shown size distribution of what's getting passed there.
You made me curious how usage compares to memcpy, so I checked 'make' in kernel dir once again.
I stress the init-on-alloc opt is *OFF*: # CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
# bpftrace -e 'kprobe:memset,kprobe:memcpy { @[probe] = count(); }' [snip] @[kprobe:memcpy]: 6948498 @[kprobe:memset]: 36150671
iow memset is used about 7 times as much as memcpy when building the kernel. If it matters I'm building on top of 2eb29d59ddf02e39774abfb60b2030b0b7e27c1f (reasonably fresh master).
> So this is literally a problem with pointless automated memset, > introduced by that hardening option. And hardening people generally > simply don't care about performance, and the people who _do _care > about performance usually don't enable the known-expensive crazy > stuff. > > Honestly, I think the INIT_ONCE stuff is actively detrimental, and > only hides issues (and in this case adds its own). So I can't but help > to say "don't do that then". I think it's literally stupid to clear > allocations by default. >
Questioning usability of the entire thing was on the menu in what I intended to write, but I did not read entire public discussion so perhaps I missed a crucial insight.
> I'm not opposed to improving memset, but honestly, if the argument is > based on the stupid hardening behavior, I really think *that* needs to > be fixed first. >
It is not. The argument is that this is a core primitive, used a lot with sizes where rep stos is detrimental to its performance. There is no urgency, but eventually someone(tm) should sort it out. For $reasons I don't want to do it myself.
I do bring it up in the context of the init-on-alloc machinery because it disfigures whatever results are obtained testing on x86-64 -- they can get exactly the same effect for much smaller cost, consequently they should have interest in sorting this out.
General point though was that the work should have sanity-checked performance of the primitive it relies on, instead of assuming it is ~optimal. I'm guilty of this mistake myself, so not going to throw stones.
-- Mateusz Guzik <mjguzik gmail.com>
| |