On 04/26/2012 12:07 AM, Minchan Kim wrote:
>
> Quick patch - totally untested.
>
> We can implement new TLB flush function
> "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.
>
> Now there are few architectures have "local_flush_tlb_kernel_range".
> MIPS, sh, unicore32, arm, score and x86 by this patch. So I think
> it's good candidate other arch should implement. Until that, we can
> add stub for other architectures which calls only [global/local] TLB
> flush. We can expect maintainer could respond then they can
> implement best efficient method. If the maintainer doesn't have any
> interest, zsmalloc could be very slow in that arch and users will
> blame that architecture.
>
> Any thoughts?
I had this same idea a while back.
It is encouraging to know that someone else independently thought of
this solution too :) Makes me think it is a good solution.
Let me build and test on x86, make sure there are no unforseen consequences.
Thanks again for your work here!
Seth
--
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>
[Site Home]
[Linux ARM Kernel]
[Linux ARM]
[Linux Omap]
[Fedora ARM]
[IETF Annouce]
[Security]
[Bugtraq]
[Linux]
[Linux OMAP]
[Linux MIPS]
[ECOS]
[Tools]
[DDR & Rambus]
[Asterisk Internet PBX]
[Linux API]
[Monitors]