On 05/17/2012 09:56 AM, Guan Xuetao wrote: > On Thu, 2012-05-17 at 09:07 +0900, Minchan Kim wrote: >> On 05/16/2012 04:28 PM, Guan Xuetao wrote: >> >>> On Wed, 2012-05-16 at 11:05 +0900, Minchan Kim wrote: >>>> zsmalloc uses set_pte and __flush_tlb_one for performance but >>>> many architecture don't support it. so this patch removes >>>> set_pte and __flush_tlb_one which are x86 dependency. >>>> Instead of it, use local_flush_tlb_kernel_range which are available >>>> by more architectures. It would be better than supporting only x86 >>>> and last patch in series will enable again with supporting >>>> local_flush_tlb_kernel_range in x86. >>>> >>>> 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. >>>> >>>> Cc: Russell King <linux@xxxxxxxxxxxxxxxx> >>>> Cc: Ralf Baechle <ralf@xxxxxxxxxxxxxx> >>>> Cc: Paul Mundt <lethal@xxxxxxxxxxxx> >>>> Cc: Guan Xuetao <gxt@xxxxxxxxxxxxxxx> >>>> Cc: Chen Liqin <liqin.chen@xxxxxxxxxxxxx> >>>> Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx> >>>> --- >>>> >>>> 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. >>>> Seth might support it in PowerPC. :) >>>> >>>> >>>> drivers/staging/zsmalloc/Kconfig | 6 ++--- >>>> drivers/staging/zsmalloc/zsmalloc-main.c | 36 +++++++++++++++++++++--------- >>>> drivers/staging/zsmalloc/zsmalloc_int.h | 1 - >>>> 3 files changed, 29 insertions(+), 14 deletions(-) >>>> >>>> diff --git a/drivers/staging/zsmalloc/Kconfig b/drivers/staging/zsmalloc/Kconfig >>>> index a5ab720..def2483 100644 >>>> --- a/drivers/staging/zsmalloc/Kconfig >>>> +++ b/drivers/staging/zsmalloc/Kconfig >>>> @@ -1,9 +1,9 @@ >>>> config ZSMALLOC >>>> tristate "Memory allocator for compressed pages" >>>> - # X86 dependency is because of the use of __flush_tlb_one and set_pte >>>> + # arch dependency is because of the use of local_unmap_kernel_range >>>> # in zsmalloc-main.c. >>>> - # TODO: convert these to portable functions >>>> - depends on X86 >>>> + # TODO: implement local_unmap_kernel_range in all architecture. >>>> + depends on (ARM || MIPS || SUPERH) >>> I suggest removing above line, so if I want to use zsmalloc, I could >>> enable this configuration easily. >> >> >> I don't get it. What do you mean? >> If I remove above line, compile error will happen if arch doesn't support local_unmap_kernel_range. > If I want to use zsmalloc, I will verify local_unmap_kernel_range > function. In fact, only local_flush_tlb_kernel_range need to be > considered. So, just keeping the default option 'n' is enough. I don't think so. It's terrible experience if all users have to look up local_flush_tlb_kernel_range of arch for using zsmalloc. BTW, does unicore32 support that function? If so, I would like to add unicore32 in Kconfig. -- 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>