Messages in this thread | | | Date | Tue, 8 Feb 2022 13:52:32 +0100 | From | Borislav Petkov <> | Subject | Re: x86: should clear_user() have alternatives? |
| |
Hi Hugh,
On Mon, Feb 07, 2022 at 09:45:36PM -0800, Hugh Dickins wrote: > I realize that dd'ing from /dev/zero to /dev/null, and sparse files on > tmpfs, are not prime candidates for optimization; and I've no idea how > much clear_user() normally gets used for long clears.
Right, we usually don't take such "optimizations" because the folks who send them always come up with either microbenchmarks or only test on a single machine.
> If I were capable of compiler asm, with alternatives, and knew at what > length ERMS becomes advantageous when clearing, I would be sending you > a proper patch. As it is, I'm hoping to tempt someone else to do the > work! Or reject it as too niche to bother with.
Yap, looking at arch/x86/lib/clear_page_64.S - that's straight-forward asm without special-cases noodles like __copy_user_nocache, for example, so I wouldn't be opposed to someone
- remodelling it so that you can have clear_user* variants there too, with the length supplied so that you can call a common function with arbitrary length and clear_page* can call it too. And then call them in a clear_user() version just like the clear_page() one which selects the proper target based on CPU feature flags.
- testing this on bunch of modern machines with, say, a kernel build or some sensible benchmark so that we at least have some coverage
If the numbers are worth it - and judging by your quick testing above they should be - then I don't mind taking that at all.
If only someone would have the time and diligence to do it properly...
:-)
Thx.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |