There isn't a single "kernel mutex" in any modern SMP kernel. Linux was pretty late to the game in abolishing 'the big kernel lock' and that work started in the early 2000s.
More to the point - if you are in the middle of shuffling the kernel around, that includes the code that tests locks/mutexes itself...
You need to, at the very least, stop all running CPUs and disable all interrupts - interrupt/trap handlers and the code they depend on are, after all, part of the kernel and among the things that will be moved around.
The entire system is now frozen. Good luck if you were doing anything remotely real-time-like. "Why is my video/audio playback skipping at regular intervals?"
Then you have to actually perform the relocation, update page tables, descriptor tables/trap handlers, and any pointers to code. Such as the method/function pointers that are very common in pretty much all kernels except perhaps the very smallest. Plus various things I forgot.
(Sidenote: How would you even solve the latter problem? Compile-time annotations and a compiler plugin? Add a "relocation callback" to all drivers and anything else?)
Some time later, when all the things are done, you can reenable interrupts and restart CPUs again.
Note that nothing of this has anything to do with bulk memory copy speeds, since changing the address mapping of the kernel has nothing (or at least very little) to do with actually moving it around in memory. The Linux kernel is always located at pretty much the same places in physical memory.
The fact that you think it does makes me imagine that your last experience with OS kernels were before the era of MMUs and paging...
Memory access speed does come into play - but it's for updating individual pointers and offsets in memory.
And all this for accomplishing exactly nothing since the attacker will have leaked the relevant address(es) and exploited the kernel sometime between your regular system-wide nap-times. Not to mention that all of this only affects code addresses and not other kernel memory.