zram/zsmalloc promotion

From: Minchan Kim [mailto:[email protected]]
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.

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.

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

Signature · 7 lines

1.7.9.5

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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?

Quoted 6 lines · 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?

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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Greg,

Quoted 10 lines · Greg Kroah-Hartman

Quoted 6 lines · 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?

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.

Quoted 1 line

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.

Quoted 2 lines

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?

Quoted 36 lines · Minchan Kim

Hi Greg,

Quoted 10 lines · Greg Kroah-Hartman

Quoted 6 lines · 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?

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.

Quoted 1 line

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.

Quoted 2 lines

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. :(

Quoted 1 line

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

Quoted 2 lines · Minchan Kim

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 5 lines · Greg Kroah-Hartman

Quoted 2 lines · Minchan Kim

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?

Quoted 9 lines · Minchan Kim

Quoted 5 lines · Greg Kroah-Hartman

Quoted 2 lines · Minchan Kim

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 8 lines

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.

Quoted 1 line

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