From: Seth Jennings <sjenning@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org,
Dan Magenheimer <dan.magenheimer@oracle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Robert Jennings <rcj@linux.vnet.ibm.com>,
Nitin Gupta <ngupta@vflare.org>
Subject: Re: [PATCH 2/3] zsmalloc: add generic path and remove x86 dependency
Date: Mon, 25 Jun 2012 13:24:29 -0500 [thread overview]
Message-ID: <4FE8ACDD.3070007@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120625171939.GA29371@kroah.com>
On 06/25/2012 12:19 PM, Greg Kroah-Hartman wrote:
> On Mon, Jun 25, 2012 at 12:10:57PM -0500, Seth Jennings wrote:
>> On 06/25/2012 11:59 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Jun 25, 2012 at 11:14:37AM -0500, Seth Jennings wrote:
>>>> This patch adds generic pages mapping methods that
>>>> work on all archs in the absence of support for
>>>> local_tlb_flush_kernel_range() advertised by the
>>>> arch through __HAVE_LOCAL_TLB_FLUSH_KERNEL_RANGE
>>>
>>> Is this #define something that other arches define now? Or is this
>>> something new that you are adding here?
>>
>> Something new I'm adding.
>
> Ah, ok.
>
>> The precedent for this approach is the __HAVE_ARCH_* defines
>> that let the arch independent stuff know if a generic
>> function needs to be defined or if there is an arch specific
>> function.
>>
>> You can "grep -R __HAVE_ARCH_* arch/x86/" to see the ones
>> that already exist.
>>
>> I guess I should have called it
>> __HAVE_ARCH_LOCAL_TLB_FLUSH_KERNEL_RANGE though, not
>> __HAVE_LOCAL_TLB_FLUSH_KERNEL_RANGE.
>
> You need to get the mm developers to agree with this before I can take
> it.
>
> But, why even depend on this? Can't you either live without it
The whole point of the patch is _not_ to depend on it. It
just performs worse without it. We could just rip out all
the the page table assisted page mapping, but, for the
arches that have support for it, we'd be degrading
performance in exchange for portability. Why choose when we
can have both?
> , or just implement it for all arches somehow?
It can be implemented for some arches and already is for
some (MIPS, ARM, at least). But for some arches, I imagine
this can't be implemented due to hardware limitations.
A benefit of this approach is the arches opt-in to the
optimized zsmalloc by implementing
local_tlb_flush_kernel_range() without having to change
anything in zsmalloc.
--
Seth
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-06-25 18:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 16:14 [PATCH 0/3] zsmalloc: remove x86 dependency Seth Jennings
2012-06-25 16:14 ` [PATCH 1/3] zram/zcache: swtich Kconfig dependency from X86 to ZSMALLOC Seth Jennings
2012-06-27 2:37 ` Minchan Kim
2012-06-27 2:43 ` Greg Kroah-Hartman
2012-06-27 2:49 ` Minchan Kim
2012-06-27 3:21 ` Greg Kroah-Hartman
2012-06-27 15:40 ` Konrad Rzeszutek Wilk
2012-06-27 18:55 ` Greg Kroah-Hartman
2012-06-27 18:52 ` Konrad Rzeszutek Wilk
2012-06-27 19:29 ` Greg Kroah-Hartman
2012-06-25 16:14 ` [PATCH 2/3] zsmalloc: add generic path and remove x86 dependency Seth Jennings
2012-06-25 16:59 ` Greg Kroah-Hartman
2012-06-25 17:10 ` Seth Jennings
2012-06-25 17:19 ` Greg Kroah-Hartman
2012-06-25 18:24 ` Seth Jennings [this message]
2012-06-25 23:37 ` Greg Kroah-Hartman
2012-06-27 5:28 ` Minchan Kim
2012-06-27 19:09 ` Seth Jennings
2012-06-28 0:20 ` Minchan Kim
2012-06-25 16:14 ` [PATCH 3/3] x86: add local_tlb_flush_kernel_range() Seth Jennings
2012-06-25 23:01 ` Konrad Rzeszutek Wilk
2012-06-26 13:39 ` Seth Jennings
2012-06-27 5:53 ` Minchan Kim
2012-06-27 6:14 ` Alex Shi
2012-06-27 6:26 ` Minchan Kim
2012-06-27 15:12 ` Dan Magenheimer
2012-06-27 15:39 ` Konrad Rzeszutek Wilk
2012-06-27 18:35 ` Seth Jennings
2012-06-27 18:33 ` Seth Jennings
2012-06-27 21:15 ` Dan Magenheimer
2012-06-27 21:41 ` Seth Jennings
2012-06-28 2:03 ` Alex Shi
2012-06-28 15:21 ` Seth Jennings
2012-06-29 0:19 ` Alex Shi
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=4FE8ACDD.3070007@linux.vnet.ibm.com \
--to=sjenning@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dan.magenheimer@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=rcj@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;
as well as URLs for NNTP newsgroup(s).