All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seth Jennings <sjenning@linux.vnet.ibm.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	Nitin Gupta <ngupta@vflare.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 6/6] zsmalloc: make zsmalloc portable
Date: Mon, 30 Apr 2012 11:24:35 -0500	[thread overview]
Message-ID: <4F9EBCC3.9040509@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F98D814.9060808@kernel.org>

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@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>

WARNING: multiple messages have this Message-ID (diff)
From: Seth Jennings <sjenning@linux.vnet.ibm.com>
To: Minchan Kim <minchan@kernel.org>
Cc: undisclosed-recipients:"; Dan Magenheimer"
	<dan.magenheimer@oracle.com>, Nitin Gupta <ngupta@vflare.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 6/6] zsmalloc: make zsmalloc portable
Date: Mon, 30 Apr 2012 11:24:35 -0500	[thread overview]
Message-ID: <4F9EBCC3.9040509@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F98D814.9060808@kernel.org>

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


  reply	other threads:[~2012-04-30 16:24 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  6:23 [PATCH 0/6] zsmalloc: clean up and fix arch dependency Minchan Kim
2012-04-25  6:23 ` Minchan Kim
2012-04-25  6:23 ` [PATCH 1/6] zsmalloc: use PageFlag macro instead of [set|test]_bit Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 12:43   ` Nitin Gupta
2012-04-25 12:43     ` Nitin Gupta
2012-04-25  6:23 ` [PATCH 2/6] zsmalloc: remove unnecessary alignment Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 12:53   ` Nitin Gupta
2012-04-25 12:53     ` Nitin Gupta
2012-04-26  1:42     ` Minchan Kim
2012-04-26  1:42       ` Minchan Kim
2012-05-03  5:16       ` Nitin Gupta
2012-05-03  5:16         ` Nitin Gupta
2012-04-25  6:23 ` [PATCH 3/6] zsmalloc: rename zspage_order with zspage_pages Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 13:03   ` Nitin Gupta
2012-04-25 13:03     ` Nitin Gupta
2012-04-26  1:46     ` Minchan Kim
2012-04-26  1:46       ` Minchan Kim
2012-04-25  6:23 ` [PATCH 4/6] zsmalloc: add/fix function comment Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 13:27   ` Nitin Gupta
2012-04-25 13:27     ` Nitin Gupta
2012-04-26  1:51     ` Minchan Kim
2012-04-26  1:51       ` Minchan Kim
2012-04-25  6:23 ` [PATCH 5/6] zsmalloc: remove unnecessary type casting Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 13:35   ` Nitin Gupta
2012-04-25 13:35     ` Nitin Gupta
2012-04-25 17:56     ` Greg Kroah-Hartman
2012-04-25 17:56       ` Greg Kroah-Hartman
2012-04-25 18:13       ` Nitin Gupta
2012-04-25 18:13         ` Nitin Gupta
2012-04-26  1:58     ` Minchan Kim
2012-04-26  1:58       ` Minchan Kim
2012-04-25  6:23 ` [PATCH 6/6] zsmalloc: make zsmalloc portable Minchan Kim
2012-04-25  6:23   ` Minchan Kim
2012-04-25 14:32   ` Nitin Gupta
2012-04-25 14:32     ` Nitin Gupta
2012-04-25 15:40     ` Dan Magenheimer
2012-04-25 15:40       ` Dan Magenheimer
2012-04-26  2:03       ` Minchan Kim
2012-04-26  2:03         ` Minchan Kim
2012-04-26  5:07         ` Minchan Kim
2012-04-26  5:07           ` Minchan Kim
2012-04-30 16:24           ` Seth Jennings [this message]
2012-04-30 16:24             ` Seth Jennings
2012-04-25 16:37     ` Seth Jennings
2012-04-25 16:37       ` Seth Jennings
2012-04-26  2:04       ` Minchan Kim
2012-04-26  2:04         ` Minchan Kim
2012-05-07 15:14       ` Seth Jennings
2012-05-07 15:14         ` Seth Jennings
2012-05-08  0:46         ` Minchan Kim
2012-05-08  0:46           ` Minchan Kim
2012-04-26  2:11   ` Minchan Kim
2012-04-26  2:11     ` Minchan Kim
2012-04-25 12:41 ` [PATCH 0/6] zsmalloc: clean up and fix arch dependency Nitin Gupta
2012-04-25 12:41   ` Nitin Gupta
2012-04-26  1:20   ` Minchan Kim
2012-04-26  1:20     ` Minchan Kim
2012-04-25 18:14 ` Greg Kroah-Hartman
2012-04-25 18:14   ` Greg Kroah-Hartman

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=4F9EBCC3.9040509@linux.vnet.ibm.com \
    --to=sjenning@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.magenheimer@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.