[PATCH v3 0/3] zram/zsmalloc promotion

[PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

This patchset promotes zram/zsmalloc from staging.
Both are very clean and zram have been used by many embedded product
for a long time.
It's time to go out of staging.

Greg, Jens is already OK that zram is located under driver/blocks/.
The issue remained is where we put zsmalloc.
The candidate is two under mm/ or under lib/
Konrad and Nitin wanted to put zsmalloc into lib/ instead of mm/.

Quote from Nitin
"
I think mm/ directory should only contain the code which is intended
for global use such as the slab allocator, page reclaim code etc.
zsmalloc is used by only one (or possibly two) drivers, so lib/ seems
to be the right place.
"

Quote from Konrand
"
I like the idea of keeping it in /lib or /mm. Actually 'lib' sounds more
appropriate since it is dealing with storing a bunch of pages in a nice
layout for great density purposes.
"

In fact, there is some history about that.

Why I put zsmalloc into under mm firstly was that Andrew had a concern
about using strut page's some fields freely in zsmalloc so he wanted
to maintain it in mm/ if I remember correctly.

So I and Nitin tried to ask the opinion to akpm several times
(at least 6 and even I sent such patch a few month ago) but didn't get
any reply from him so I guess he doesn't have any concern about that
any more.

In point of view that it's an another slab-like allocator,
it might be proper under mm but it's not popular as current mm's
allocators(/SLUB/SLOB and page allocator).

Frankly speaking, I don't care whether we put it to mm/ or lib/.
It seems contributors(ex, Nitin and Konrad) like lib/ and Andrew is still
silent. That's why I am biased into lib/ now.

If someone yell we should keep it to mm/ by logical claim, I can change
my mind easily. Please raise your hand.

If Andrew doesn't have a concern about that any more, I would like to
locate it into /lib.

This patchset is based on next-20121029

Minchan Kim (3):
  zsmalloc: promote to lib/
  zram: promote zram from staging
  zram: select ZSMALLOC when ZRAM is configured

 drivers/block/Kconfig                    |    1 +
 drivers/block/Makefile                   |    1 +
 drivers/block/zram/Kconfig               |   26 +
 drivers/block/zram/Makefile              |    3 +
 drivers/block/zram/zram.txt              |   76 +++
 drivers/block/zram/zram_drv.c            |  793 ++++++++++++++++++++++
 drivers/block/zram/zram_drv.h            |  119 ++++
 drivers/block/zram/zram_sysfs.c          |  225 +++++++
 drivers/staging/Kconfig                  |    4 -
 drivers/staging/Makefile                 |    1 -
 drivers/staging/zcache/zcache-main.c     |    4 +-
 drivers/staging/zram/Kconfig             |   25 -
 drivers/staging/zram/Makefile            |    3 -
 drivers/staging/zram/zram.txt            |   76 ---
 drivers/staging/zram/zram_drv.c          |  793 ----------------------
 drivers/staging/zram/zram_drv.h          |  120 ----
 drivers/staging/zram/zram_sysfs.c        |  225 -------
 drivers/staging/zsmalloc/Kconfig         |   10 -
 drivers/staging/zsmalloc/Makefile        |    3 -
 drivers/staging/zsmalloc/zsmalloc-main.c | 1064 ------------------------------
 drivers/staging/zsmalloc/zsmalloc.h      |   43 --
 include/linux/zsmalloc.h                 |   43 ++
 lib/Kconfig                              |   18 +
 lib/Makefile                             |    1 +
 lib/zsmalloc.c                           | 1064 ++++++++++++++++++++++++++++++
 25 files changed, 2372 insertions(+), 2369 deletions(-)
 create mode 100644 drivers/block/zram/Kconfig
 create mode 100644 drivers/block/zram/Makefile
 create mode 100644 drivers/block/zram/zram.txt
 create mode 100644 drivers/block/zram/zram_drv.c
 create mode 100644 drivers/block/zram/zram_drv.h
 create mode 100644 drivers/block/zram/zram_sysfs.c
 delete mode 100644 drivers/staging/zram/Kconfig
 delete mode 100644 drivers/staging/zram/Makefile
 delete mode 100644 drivers/staging/zram/zram.txt
 delete mode 100644 drivers/staging/zram/zram_drv.c
 delete mode 100644 drivers/staging/zram/zram_drv.h
 delete mode 100644 drivers/staging/zram/zram_sysfs.c
 delete mode 100644 drivers/staging/zsmalloc/Kconfig
 delete mode 100644 drivers/staging/zsmalloc/Makefile
 delete mode 100644 drivers/staging/zsmalloc/zsmalloc-main.c
 delete mode 100644 drivers/staging/zsmalloc/zsmalloc.h
 create mode 100644 include/linux/zsmalloc.h
 create mode 100644 lib/zsmalloc.c

-- 
1.7.9.5

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

RE: [PATCH v3 0/3] zram/zsmalloc promotion

[Dan Magenheimer]

> From: Minchan Kim [mailto:minchan@kernel.org]
> Subject: [PATCH v3 0/3] zram/zsmalloc promotion
> 
> The candidate is two under mm/ or under lib/
> Konrad and Nitin wanted to put zsmalloc into lib/ instead of mm/.
> 
> Quote from Nitin
> "
> I think mm/ directory should only contain the code which is intended
> for global use such as the slab allocator, page reclaim code etc.
> zsmalloc is used by only one (or possibly two) drivers, so lib/ seems
> to be the right place.
> "
> 
> Quote from Konrand
> "
> I like the idea of keeping it in /lib or /mm. Actually 'lib' sounds more
> appropriate since it is dealing with storing a bunch of pages in a nice
> layout for great density purposes.
> "
> 
> In fact, there is some history about that.
> 
> Why I put zsmalloc into under mm firstly was that Andrew had a concern
> about using strut page's some fields freely in zsmalloc so he wanted
> to maintain it in mm/ if I remember correctly.
> 
> So I and Nitin tried to ask the opinion to akpm several times
> (at least 6 and even I sent such patch a few month ago) but didn't get
> any reply from him so I guess he doesn't have any concern about that
> any more.
> 
> In point of view that it's an another slab-like allocator,
> it might be proper under mm but it's not popular as current mm's
> allocators(/SLUB/SLOB and page allocator).
> 
> Frankly speaking, I don't care whether we put it to mm/ or lib/.
> It seems contributors(ex, Nitin and Konrad) like lib/ and Andrew is still
> silent. That's why I am biased into lib/ now.
> 
> If someone yell we should keep it to mm/ by logical claim, I can change
> my mind easily. Please raise your hand.
> 
> If Andrew doesn't have a concern about that any more, I would like to
> locate it into /lib.

FWIW, I would vote for /lib as well.

Dan

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

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Seth Jennings]

On 10/29/2012 03:56 AM, Minchan Kim wrote:
> This patchset promotes zram/zsmalloc from staging.
> Both are very clean and zram have been used by many embedded product
> for a long time.
> It's time to go out of staging.

Agreed!

> Greg, Jens is already OK that zram is located under driver/blocks/.
> The issue remained is where we put zsmalloc.

Doesn't matter much for me, but seems to be leaning toward /lib,
baring an opinion from Andrew that it go in /mm.  /lib is fine by me.

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>

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

Thanks all,

At last, everybody who contributes to zsmalloc want to put it under /lib.

Greg,
What should I do for promoting this dragging patchset?

On Mon, Oct 29, 2012 at 05:56:46PM +0900, Minchan Kim wrote:
> This patchset promotes zram/zsmalloc from staging.
> Both are very clean and zram have been used by many embedded product
> for a long time.
> It's time to go out of staging.
> 
> Greg, Jens is already OK that zram is located under driver/blocks/.
> The issue remained is where we put zsmalloc.
> The candidate is two under mm/ or under lib/
> Konrad and Nitin wanted to put zsmalloc into lib/ instead of mm/.
> 
> Quote from Nitin
> "
> I think mm/ directory should only contain the code which is intended
> for global use such as the slab allocator, page reclaim code etc.
> zsmalloc is used by only one (or possibly two) drivers, so lib/ seems
> to be the right place.
> "
> 
> Quote from Konrand
> "
> I like the idea of keeping it in /lib or /mm. Actually 'lib' sounds more
> appropriate since it is dealing with storing a bunch of pages in a nice
> layout for great density purposes.
> "
> 
> In fact, there is some history about that.
> 
> Why I put zsmalloc into under mm firstly was that Andrew had a concern
> about using strut page's some fields freely in zsmalloc so he wanted
> to maintain it in mm/ if I remember correctly.
> 
> So I and Nitin tried to ask the opinion to akpm several times
> (at least 6 and even I sent such patch a few month ago) but didn't get
> any reply from him so I guess he doesn't have any concern about that
> any more.
> 
> In point of view that it's an another slab-like allocator,
> it might be proper under mm but it's not popular as current mm's
> allocators(/SLUB/SLOB and page allocator).
> 
> Frankly speaking, I don't care whether we put it to mm/ or lib/.
> It seems contributors(ex, Nitin and Konrad) like lib/ and Andrew is still
> silent. That's why I am biased into lib/ now.
> 
> If someone yell we should keep it to mm/ by logical claim, I can change
> my mind easily. Please raise your hand.
> 
> If Andrew doesn't have a concern about that any more, I would like to
> locate it into /lib.
> 
> This patchset is based on next-20121029
> 
> Minchan Kim (3):
>   zsmalloc: promote to lib/
>   zram: promote zram from staging
>   zram: select ZSMALLOC when ZRAM is configured
> 
>  drivers/block/Kconfig                    |    1 +
>  drivers/block/Makefile                   |    1 +
>  drivers/block/zram/Kconfig               |   26 +
>  drivers/block/zram/Makefile              |    3 +
>  drivers/block/zram/zram.txt              |   76 +++
>  drivers/block/zram/zram_drv.c            |  793 ++++++++++++++++++++++
>  drivers/block/zram/zram_drv.h            |  119 ++++
>  drivers/block/zram/zram_sysfs.c          |  225 +++++++
>  drivers/staging/Kconfig                  |    4 -
>  drivers/staging/Makefile                 |    1 -
>  drivers/staging/zcache/zcache-main.c     |    4 +-
>  drivers/staging/zram/Kconfig             |   25 -
>  drivers/staging/zram/Makefile            |    3 -
>  drivers/staging/zram/zram.txt            |   76 ---
>  drivers/staging/zram/zram_drv.c          |  793 ----------------------
>  drivers/staging/zram/zram_drv.h          |  120 ----
>  drivers/staging/zram/zram_sysfs.c        |  225 -------
>  drivers/staging/zsmalloc/Kconfig         |   10 -
>  drivers/staging/zsmalloc/Makefile        |    3 -
>  drivers/staging/zsmalloc/zsmalloc-main.c | 1064 ------------------------------
>  drivers/staging/zsmalloc/zsmalloc.h      |   43 --
>  include/linux/zsmalloc.h                 |   43 ++
>  lib/Kconfig                              |   18 +
>  lib/Makefile                             |    1 +
>  lib/zsmalloc.c                           | 1064 ++++++++++++++++++++++++++++++
>  25 files changed, 2372 insertions(+), 2369 deletions(-)
>  create mode 100644 drivers/block/zram/Kconfig
>  create mode 100644 drivers/block/zram/Makefile
>  create mode 100644 drivers/block/zram/zram.txt
>  create mode 100644 drivers/block/zram/zram_drv.c
>  create mode 100644 drivers/block/zram/zram_drv.h
>  create mode 100644 drivers/block/zram/zram_sysfs.c
>  delete mode 100644 drivers/staging/zram/Kconfig
>  delete mode 100644 drivers/staging/zram/Makefile
>  delete mode 100644 drivers/staging/zram/zram.txt
>  delete mode 100644 drivers/staging/zram/zram_drv.c
>  delete mode 100644 drivers/staging/zram/zram_drv.h
>  delete mode 100644 drivers/staging/zram/zram_sysfs.c
>  delete mode 100644 drivers/staging/zsmalloc/Kconfig
>  delete mode 100644 drivers/staging/zsmalloc/Makefile
>  delete mode 100644 drivers/staging/zsmalloc/zsmalloc-main.c
>  delete mode 100644 drivers/staging/zsmalloc/zsmalloc.h
>  create mode 100644 include/linux/zsmalloc.h
>  create mode 100644 lib/zsmalloc.c
> 
> -- 
> 1.7.9.5
> 
> --
> 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>

-- 
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Greg Kroah-Hartman]

On Wed, Oct 31, 2012 at 10:06:42AM +0900, Minchan Kim wrote:
> Thanks all,
> 
> At last, everybody who contributes to zsmalloc want to put it under /lib.
> 
> Greg,
> What should I do for promoting this dragging patchset?

You need to get the -mm developers to agree that this is something that
is worth accepting.  I have yet to see any compeling argument why this
even needs to be in the kernel in the first place.

I'm not moving this anywhere until you get their acceptance.

greg k-h

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

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

Hi Greg,

On Tue, Oct 30, 2012 at 06:42:09PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 31, 2012 at 10:06:42AM +0900, Minchan Kim wrote:
> > Thanks all,
> > 
> > At last, everybody who contributes to zsmalloc want to put it under /lib.
> > 
> > Greg,
> > What should I do for promoting this dragging patchset?
> 
> You need to get the -mm developers to agree that this is something that
> is worth accepting.  I have yet to see any compeling argument why this

I'm one of mm developers. :)
Yes. I hope Andrew have a time to take a look.

> even needs to be in the kernel in the first place.

Confused. what do you mean "this"? "zsmalloc" or "zram" or "both"?
If you mean "zsmalloc", I guess there were some lengthy thread about
"why we need a new another allocator". Unfortunately, I didn't follow it
at that time. Nitin, Pekka, Could you point out that thread? or summarize
the result.

> 
> I'm not moving this anywhere until you get their acceptance.

I understand you.

It's one of problem in current mm mailing list.
As you know, many mm guys works for server, not embedded so they don't have
big interest about embedded feature so prioirty of the feature was always
low. CMA proved it and next turn is zram. Even new-comer in mm is few so
review bandwidth is always low, too. :(

How can I poke them?
The only thing I can do is just (wait, repost) * 5?
Sigh. :(

> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Greg Kroah-Hartman]

On Wed, Oct 31, 2012 at 11:04:43AM +0900, Minchan Kim wrote:
> Hi Greg,
> 
> On Tue, Oct 30, 2012 at 06:42:09PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 31, 2012 at 10:06:42AM +0900, Minchan Kim wrote:
> > > Thanks all,
> > > 
> > > At last, everybody who contributes to zsmalloc want to put it under /lib.
> > > 
> > > Greg,
> > > What should I do for promoting this dragging patchset?
> > 
> > You need to get the -mm developers to agree that this is something that
> > is worth accepting.  I have yet to see any compeling argument why this
> 
> I'm one of mm developers. :)
> Yes. I hope Andrew have a time to take a look.
> 
> > even needs to be in the kernel in the first place.
> 
> Confused. what do you mean "this"? "zsmalloc" or "zram" or "both"?
> If you mean "zsmalloc", I guess there were some lengthy thread about
> "why we need a new another allocator". Unfortunately, I didn't follow it
> at that time. Nitin, Pekka, Could you point out that thread? or summarize
> the result.
> 
> > 
> > I'm not moving this anywhere until you get their acceptance.
> 
> I understand you.
> 
> It's one of problem in current mm mailing list.
> As you know, many mm guys works for server, not embedded so they don't have
> big interest about embedded feature so prioirty of the feature was always
> low. CMA proved it and next turn is zram. Even new-comer in mm is few so
> review bandwidth is always low, too. :(
> 
> How can I poke them?

You just did.  If they ignore this, wait a week, and resend.
Persistance is key.

good luck,

greg k-h

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

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

On Tue, Oct 30, 2012 at 07:16:18PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 31, 2012 at 11:04:43AM +0900, Minchan Kim wrote:
> > Hi Greg,
> > 
> > On Tue, Oct 30, 2012 at 06:42:09PM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Oct 31, 2012 at 10:06:42AM +0900, Minchan Kim wrote:
> > > > Thanks all,
> > > > 
> > > > At last, everybody who contributes to zsmalloc want to put it under /lib.
> > > > 
> > > > Greg,
> > > > What should I do for promoting this dragging patchset?
> > > 
> > > You need to get the -mm developers to agree that this is something that
> > > is worth accepting.  I have yet to see any compeling argument why this
> > 
> > I'm one of mm developers. :)
> > Yes. I hope Andrew have a time to take a look.
> > 
> > > even needs to be in the kernel in the first place.
> > 
> > Confused. what do you mean "this"? "zsmalloc" or "zram" or "both"?
> > If you mean "zsmalloc", I guess there were some lengthy thread about
> > "why we need a new another allocator". Unfortunately, I didn't follow it
> > at that time. Nitin, Pekka, Could you point out that thread? or summarize
> > the result.
> > 
> > > 
> > > I'm not moving this anywhere until you get their acceptance.
> > 
> > I understand you.
> > 
> > It's one of problem in current mm mailing list.
> > As you know, many mm guys works for server, not embedded so they don't have
> > big interest about embedded feature so prioirty of the feature was always
> > low. CMA proved it and next turn is zram. Even new-comer in mm is few so
> > review bandwidth is always low, too. :(
> > 
> > How can I poke them?
> 
> You just did.  If they ignore this, wait a week, and resend.
> Persistance is key.
> 
> good luck,

Okay. I will wait.
Greg, what do you think about LTSI?
Is it proper feature to add it? For it, still do I need ACK from mm developers?

> 
> greg k-h
> 
> --
> 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>

-- 
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Greg Kroah-Hartman]

On Wed, Oct 31, 2012 at 11:39:48AM +0900, Minchan Kim wrote:
> Greg, what do you think about LTSI?
> Is it proper feature to add it? For it, still do I need ACK from mm developers?

It's already in LTSI, as it's in the 3.4 kernel, right?

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

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

On Tue, Oct 30, 2012 at 07:43:07PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 31, 2012 at 11:39:48AM +0900, Minchan Kim wrote:
> > Greg, what do you think about LTSI?
> > Is it proper feature to add it? For it, still do I need ACK from mm developers?
> 
> It's already in LTSI, as it's in the 3.4 kernel, right?

Right. But as I look, it seems to be based on 3.4.11 which doesn't have
recent bug fix and enhances and current 3.4.16 also doesn't include it.

Just out of curiosity.

Is there any rule about update period in long-term kernel?
I mean how often you release long-term kernel.

Is there any rule about update period in LTSI kernel based on long-term kernel?
If I get the answer on above two quesion, I can expect later what LTSI kernel
version include feature I need.

Another question.
For example, There is A feature in mainline and A has no problem but
someone invents new wheel "B" which is better than A so it replace A totally
in recent mainline. As following stable-kernel rule, it's not a real bug fix
so I guess stable kernel will never replace A with B. It means LTSI never get
a chance to use new wheel. Right?

Thanks.

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

-- 
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Greg Kroah-Hartman]

On Wed, Oct 31, 2012 at 04:02:02PM +0900, Minchan Kim wrote:
> On Tue, Oct 30, 2012 at 07:43:07PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 31, 2012 at 11:39:48AM +0900, Minchan Kim wrote:
> > > Greg, what do you think about LTSI?
> > > Is it proper feature to add it? For it, still do I need ACK from mm developers?
> > 
> > It's already in LTSI, as it's in the 3.4 kernel, right?
> 
> Right. But as I look, it seems to be based on 3.4.11 which doesn't have
> recent bug fix and enhances and current 3.4.16 also doesn't include it.

You can ask for those bugfixes to get backported to the stable/longterm
kernel tree, see Documentation/stable_kernel_rules.txt for how to do
this properly.

> Just out of curiosity.
> 
> Is there any rule about update period in long-term kernel?
> I mean how often you release long-term kernel.

About once a week lately.

> Is there any rule about update period in LTSI kernel based on long-term kernel?

No, the LTSI kernel work has been slow due to the lack of time on my
part lately.

> If I get the answer on above two quesion, I can expect later what LTSI kernel
> version include feature I need.
> 
> Another question.
> For example, There is A feature in mainline and A has no problem but
> someone invents new wheel "B" which is better than A so it replace A totally
> in recent mainline. As following stable-kernel rule, it's not a real bug fix
> so I guess stable kernel will never replace A with B.

That is correct.

> It means LTSI never get a chance to use new wheel. Right?

No, you can submit the same patches for the LTSI kernel as well, they
will probably be accepted as the rules are much more "loose" for the
LTSI tree compared to the normal stable/longterm kernel rules.  Which is
the primary reason it is around.

Hope this helps,

greg k-h

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

Re: [PATCH v3 0/3] zram/zsmalloc promotion

[Minchan Kim]

On Wed, Oct 31, 2012 at 09:19:00AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 31, 2012 at 04:02:02PM +0900, Minchan Kim wrote:
> > On Tue, Oct 30, 2012 at 07:43:07PM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Oct 31, 2012 at 11:39:48AM +0900, Minchan Kim wrote:
> > > > Greg, what do you think about LTSI?
> > > > Is it proper feature to add it? For it, still do I need ACK from mm developers?
> > > 
> > > It's already in LTSI, as it's in the 3.4 kernel, right?
> > 
> > Right. But as I look, it seems to be based on 3.4.11 which doesn't have
> > recent bug fix and enhances and current 3.4.16 also doesn't include it.
> 
> You can ask for those bugfixes to get backported to the stable/longterm
> kernel tree, see Documentation/stable_kernel_rules.txt for how to do
> this properly.
> 
> > Just out of curiosity.
> > 
> > Is there any rule about update period in long-term kernel?
> > I mean how often you release long-term kernel.
> 
> About once a week lately.
> 
> > Is there any rule about update period in LTSI kernel based on long-term kernel?
> 
> No, the LTSI kernel work has been slow due to the lack of time on my
> part lately.
> 
> > If I get the answer on above two quesion, I can expect later what LTSI kernel
> > version include feature I need.
> > 
> > Another question.
> > For example, There is A feature in mainline and A has no problem but
> > someone invents new wheel "B" which is better than A so it replace A totally
> > in recent mainline. As following stable-kernel rule, it's not a real bug fix
> > so I guess stable kernel will never replace A with B.
> 
> That is correct.
> 
> > It means LTSI never get a chance to use new wheel. Right?
> 
> No, you can submit the same patches for the LTSI kernel as well, they
> will probably be accepted as the rules are much more "loose" for the
> LTSI tree compared to the normal stable/longterm kernel rules.  Which is
> the primary reason it is around.
> 
> Hope this helps,
> 
> greg k-h

Thanks, Greg!

-- 
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>