Messages in this thread | | | Date | Thu, 17 May 2012 17:32:13 +0900 | From | Paul Mundt <> | Subject | Re: [PATCH v2 1/3] zsmalloc: support zsmalloc to ARM, MIPS, SUPERH |
| |
On Wed, May 16, 2012 at 11:05:17AM +0900, Minchan Kim wrote: > About local_flush_tlb_kernel_range, > If architecture is very smart, it could flush only tlb entries related to vaddr. > If architecture is smart, it could flush only tlb entries related to a CPU. > If architecture is _NOT_ smart, it could flush all entries of all CPUs. > So, it would be best to support both portability and performance. > ..
> Need double check about supporting local_flush_tlb_kernel_range > in ARM, MIPS, SUPERH maintainers. And I will Ccing unicore32 and > score maintainers because arch directory in those arch have > local_flush_tlb_kernel_range, too but I'm very unfamiliar with those > architecture so pass it to maintainers. > I didn't coded up dumb local_flush_tlb_kernel_range which flush > all cpus. I expect someone need ZSMALLOC will implement it easily in future. >
One thing you might consider is providing a stubbed definition that wraps to flush_tlb_kernel_range() in the !SMP case, as this will extend your testing coverage for staging considerably.
Once you exclude all of the non-SMP platforms, you're left with the following:
- blackfin: doesn't count, no TLB to worry about. - hexagon: seems to imply that the SMP case uses thread-based CPUs that share an MMU, so no additional cost. - ia64: Does a global flush, which already has a FIXME comment. - m32r, mn10300: local_flush_tlb_all() could be wrapped. - parisc: global flush? - s390: Tests the cpumask to do a local flush, otherwise has a __tlb_flush_local() that can be wrapped. - sparc32: global flush - sparc64: __flush_tlb_kernel_range() looks like a local flush. - tile: does strange hypervisory things, presumably global. - x86: has a local_flush_tlb() that could be wrapped.
Which doesn't look quite that bad. You could probably get away with a Kconfig option for optimized local TLB flushing or something, since single function Kconfig options seem to be all the rage these days.
| |