From: Minchan Kim <minchan@kernel.org>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nitin Gupta <ngupta@vflare.org>,
Seth Jennings <sjenning@linux.vnet.ibm.com>,
Dan Magenheimer <dan.magenheimer@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Russell King <linux@arm.linux.org.uk>,
Ralf Baechle <ralf@linux-mips.org>,
Guan Xuetao <gxt@mprc.pku.edu.cn>,
Chen Liqin <liqin.chen@sunplusct.com>
Subject: Re: [PATCH v2 1/3] zsmalloc: support zsmalloc to ARM, MIPS, SUPERH
Date: Thu, 17 May 2012 18:08:13 +0900 [thread overview]
Message-ID: <4FB4BFFD.5030508@kernel.org> (raw)
In-Reply-To: <20120517083213.GC14027@linux-sh.org>
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.
>
> 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.
I missed this sentence.
Thanks for very helpful comment, Paul!
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. 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@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-17 9:07 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 2:05 Minchan Kim
2012-05-16 2:05 ` [PATCH v2 2/3] remove dependency with x86 Minchan Kim
2012-05-16 17:11 ` Seth Jennings
2012-05-17 8:06 ` Minchan Kim
2012-05-16 2:05 ` [PATCH v2 3/3] x86: Support local_flush_tlb_kernel_range Minchan Kim
2012-05-17 8:11 ` Minchan Kim
2012-05-17 14:46 ` Greg Kroah-Hartman
2012-05-18 8:35 ` Minchan Kim
2012-05-17 14:51 ` Peter Zijlstra
2012-05-17 15:08 ` Peter Zijlstra
2012-05-19 0:13 ` Alex Shi
2012-05-18 8:36 ` Minchan Kim
2012-06-15 15:13 ` Seth Jennings
2012-06-15 16:35 ` Dan Magenheimer
2012-06-15 16:45 ` Nitin Gupta
2012-06-15 17:29 ` Dan Magenheimer
2012-06-15 19:07 ` Seth Jennings
2012-06-15 19:39 ` Dan Magenheimer
2012-06-15 19:53 ` Nitin Gupta
2012-06-15 20:13 ` Dan Magenheimer
2012-06-15 21:23 ` Nitin Gupta
2012-06-15 23:26 ` Seth Jennings
2012-06-15 16:48 ` Seth Jennings
2012-05-16 7:28 ` [PATCH v2 1/3] zsmalloc: support zsmalloc to ARM, MIPS, SUPERH Guan Xuetao
2012-05-17 0:07 ` Minchan Kim
2012-05-17 0:56 ` Guan Xuetao
2012-05-17 8:04 ` Minchan Kim
2012-05-18 1:45 ` Guan Xuetao
2012-05-18 8:38 ` Minchan Kim
2012-05-17 8:32 ` Paul Mundt
2012-05-17 9:06 ` Minchan Kim
2012-05-17 9:19 ` Paul Mundt
2012-05-17 9:08 ` Minchan Kim [this message]
2012-05-23 20:51 ` Seth Jennings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB4BFFD.5030508@kernel.org \
--to=minchan@kernel.org \
--cc=dan.magenheimer@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=gxt@mprc.pku.edu.cn \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=liqin.chen@sunplusct.com \
--cc=ngupta@vflare.org \
--cc=ralf@linux-mips.org \
--cc=sjenning@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox