On 05/17/2012 05:32 PM, Paul Mundt wrote:
> 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.
AFAIUC, you mean following as,
ifndef CONFIG_SMP
void flush_tlb_kernel_range(unsinged long start, unsigned log end)
{
local_flush_tlb_kernel_range(start, end);
}
#endif
I can do it on some arch which I know a little bit but concern is
I'm not sure what's effective between all entries flush and
each entry flush if range is very big.
It's not a goal of this patch so I would like to pass it to arch maintainers.
But I absolutely agree on testing coverage on your comment.
>
> 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.
Actually, I didn't want to implement dumb flush functions on all architecture
which those functions flush all entries although we need flush a few entries.
It might zsmalloc unuseful so I expected each maintainers can implement
it much efficient than stupid me and then, they add their arch in Kconfig. :(
If this approach is really bad, I need time to implement dumb stub functions
in all architecture and have to receive all acks from them. Sigh.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxx. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
>
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>