This is the slowest and greatest latency-inducing loop in the MicroBlaze
kernel. The CPU specs says icache must be disabled while you clear it -
if you have a chance it's worth checking to see what happens if you
violate that rule.
This will be less of a problem once we update the kernel_from_bram
patches, but that may be a little while yet.
ditto
This could be smarter - if our cache size is less than a page then there
is a win to be had. But, it's my fault so I won't complain too loudly!
and again.
Perhaps a #define in asm-microblaze/signal.h to tell us the size of the
sigtramp, and also used by microblaze/kernel/signal.c?
again might be worth testing if it still works with dcache enabled
during the flush loop.
Is this actually used anywhere? If so, it's wrong because cache line
sizes is configurable now.
If you are throwing out the alloc_consist()/free_consist()
implementation then the UNCACHED_SHADOW stuff can go too.
Is the icache flush required? Is copy_to_user_page() called from the
binfmt_flat loader?
--