Paul indicated:
> +cache-lock.txt
> + - HOWTO for blackfin cache locking.
> +
This is a generic enough of a feature that I suspect we should hash out a
common API for it rather than having people roll their own.
That sounds like a good idea. From the few people that use this, I think a
much simpler interface would be desirable.
For data, it is easy - something similar to the processor specific
xx_flush_range(start,end) - have a xxx_lock_range(start,end) would be good,
and easy to implement.
The only thing I am not sure of - is how to force things into cache. For
data - it is easy - do a read, and then lock it. For instruction - for
those architectures which have separate instruction cache (like Blackfin)
it is much harder. The only way to get code into cache is to execute it.
(ergo the existing interface).
Normally - what we do when locking things in cache is specific to the hardware.
- to prevent isr polluting cache, we disable interrupts
- If the code to be locked has a possibility of already being in the
instruction cache, we invalidate the entire cache first
- we locks 3/4 of the cache - forcing any code to be put into a specific
location.
- execute the code of interest (once)
- unlock the 3/4 of cache, and lock the 1/4 where the code of interest
is located.
- turn back on interrupts.
Because the algorithm is so specific to the hardware - I am not sure how to
make instruction as generic as data could be.
How does SH cache handle things like this?
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
