Re: [PATCH 0/7] zram/zsmalloc promotion
On Thu, Aug 16, 2012 at 10:47:58PM -0700, Nitin Gupta wrote: > On 08/13/2012 11:22 PM, Minchan Kim wrote: > > Hi Greg, > > > > On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: > >> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > >>> This patchset promotes zram/zsmalloc from staging. > >>> Both are very clean and zram is used by many embedded product > >>> for a long time. > >>> > >>> [1-3] are patches not merged into linux-next yet but needed > >>> it as base for [4-5] which promotes zsmalloc. > >>> Greg, if you merged [1-3] already, skip them. > >> > >> I've applied 1-3 and now 4, but that's it, I can't apply the rest > > > > Thanks! > > > >> without getting acks from the -mm maintainers, sorry. Please work with > > > > Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want > > to confirm it from akpm so let's wait his opinion. > > > > akpm, please? To Nitin Now both zram/zcache uses zsmalloc so I think second place is under /lib than /zram if we really want to put it out of /mm but my preference is still under /mm. If akpm don't oppose, I will do. (Let's not consider removal of zsmalloc in zcache at the moment because it's just Dan's trial and it's not realized yet. It's very twisted problem and I don't expect it will finish soon :( ) To akpm, I would like to put zsmalloc under /mm because it uses a few field of struct page freely. IIRC, you pointed out, too. What do you think about it? If you don't want, I will put zsmalloc under /lib. To Jens, I would like to put zram under driver/blocks. Can I get your Ack? > > > Anyway, another question. zram would be under driver/blocks. > > Do I need ACK from Jens for that? > > > > Added Jens to CC list. > > Thanks, > Nitin > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Thu, Aug 16, 2012 at 10:47:58PM -0700, Nitin Gupta wrote: On 08/13/2012 11:22 PM, Minchan Kim wrote: Hi Greg, On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest Thanks! without getting acks from the -mm maintainers, sorry. Please work with Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want to confirm it from akpm so let's wait his opinion. akpm, please? To Nitin Now both zram/zcache uses zsmalloc so I think second place is under /lib than /zram if we really want to put it out of /mm but my preference is still under /mm. If akpm don't oppose, I will do. (Let's not consider removal of zsmalloc in zcache at the moment because it's just Dan's trial and it's not realized yet. It's very twisted problem and I don't expect it will finish soon :( ) To akpm, I would like to put zsmalloc under /mm because it uses a few field of struct page freely. IIRC, you pointed out, too. What do you think about it? If you don't want, I will put zsmalloc under /lib. To Jens, I would like to put zram under driver/blocks. Can I get your Ack? Anyway, another question. zram would be under driver/blocks. Do I need ACK from Jens for that? Added Jens to CC list. Thanks, Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/13/2012 11:22 PM, Minchan Kim wrote: > Hi Greg, > > On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: >> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: >>> This patchset promotes zram/zsmalloc from staging. >>> Both are very clean and zram is used by many embedded product >>> for a long time. >>> >>> [1-3] are patches not merged into linux-next yet but needed >>> it as base for [4-5] which promotes zsmalloc. >>> Greg, if you merged [1-3] already, skip them. >> >> I've applied 1-3 and now 4, but that's it, I can't apply the rest > > Thanks! > >> without getting acks from the -mm maintainers, sorry. Please work with > > Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want > to confirm it from akpm so let's wait his opinion. > akpm, please? > Anyway, another question. zram would be under driver/blocks. > Do I need ACK from Jens for that? > Added Jens to CC list. Thanks, Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/13/2012 11:22 PM, Minchan Kim wrote: Hi Greg, On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest Thanks! without getting acks from the -mm maintainers, sorry. Please work with Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want to confirm it from akpm so let's wait his opinion. akpm, please? Anyway, another question. zram would be under driver/blocks. Do I need ACK from Jens for that? Added Jens to CC list. Thanks, Nitin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/7] zram/zsmalloc promotion
> > On a second thought, I think zsmalloc should stay in drivers/block/zram > > since zram is now the only user of zsmalloc since zcache and ramster are > > moving to another allocator. > > The removal of zsmalloc from zcache has not been agreed upon > yet. > > Dan _suggested_ removing zsmalloc as the persistent > allocator for zcache in favor of zbud to solve "flaws" in > zcache. (Correction: Dan has _coded_, _tested_ and _published_ _working_ code that removes zsmalloc ;-) > However, zbud has large deficiencies. > > A zero-filled 4k page will compress with LZO to 103 bytes. > zbud can only store two compressed pages in each memory pool > page, resulting in 95% fragmentation (i.e. 95% of the memory > pool page goes unused). While this might not be a typical > case, it is the worst case and absolutely does happen. > > zbud's design also effectively limits the useful page > compression to 50%. If pages are compressed beyond that, the > added space savings is lost in memory pool fragmentation. > For example, if two pages compress to 30% of their original > size, those two pages take up 60% of the zbud memory pool > page, and 40% is lost to fragmentation because zbud can't > store anything in the remaining space. > > To say it another way, for every two page cache pages that > cleancache stores in zcache, zbud _must_ allocate a memory > pool page, regardless of how well those pages compress. > This reduces the efficiency of the page cache reclaim > mechanism by half. All very true, but these are not zbud deficiencies. They are design choices to ensure predictability so that pageframes can be reclaimed when the cache gets full. NOT zpages but complete pageframes, since this is what the rest of the kernel uses. And zbud handles LRU ordering also. Basic computer science principles tell us that maximizing storage density (as zsmalloc does) has major negative consequences especially when random fragments are freed, as is true for the random frontswap access patterns. You don't get higher density without much higher complexity. This is a fundamental design tradeoff for zcache. > I have posted some work (zsmalloc shrinker interface, user > registered alloc/free functions for the zsmalloc memory > pool) that begins to make zsmalloc a suitable replacement > for zbud, but that work was put on hold until the path out > of staging was established. > > I'm hoping to continue this work once the code is in > mainline. While zbud has deficiencies, it doesn't prevent > zcache from having value as I have already demonstrated. > However, replacing zsmalloc with zbud would step backward > for the reasons mentioned above. Please do continue this work. But there was no indication that you had even begun to think through all the consequences of concurrent access or LRU pageframe reclaim. I did think through them and concluded that the issues were far more complex with zsmalloc than zbud (and would be happy to explain further). So I solved the issues with zbud and got both parts of zcache (frontswap and cleancache) working fully with zbud. In other words, IMHO the existing zsmalloc will need to evolve a great deal to work with the complete needs of zcache. If you can get both maximal density AND concurrency AND LRU pageframe reclaim all working with zsmalloc, and fully test it (with zcache) and publish it, I would support moving to this "new" zsmalloc instantly. > I do not support the removal of zsmalloc from zcache. As > such, I think the zsmalloc code should remain independent. Zcache must move forward to meet the needs of a broader set of workloads and distros and users, not just the limited toy benchmarking you have provided. Zsmalloc has not yet proven capable of meeting those needs. It may be capable in the future but it cannot meet them now. Dan P.S. I think zsmalloc IS a good match for zram so I do not object to the promotion of zsmalloc as part of promoting zram. Would be happy to explain technical details further if this surprises anyone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Tue, Aug 14, 2012 at 12:39:25PM -0500, Seth Jennings wrote: > On 08/14/2012 12:36 AM, Nitin Gupta wrote: > > On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: > >> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > >>> This patchset promotes zram/zsmalloc from staging. > >>> Both are very clean and zram is used by many embedded product > >>> for a long time. > >>> > >>> [1-3] are patches not merged into linux-next yet but needed > >>> it as base for [4-5] which promotes zsmalloc. > >>> Greg, if you merged [1-3] already, skip them. > >> > >> I've applied 1-3 and now 4, but that's it, I can't apply the rest > >> without getting acks from the -mm maintainers, sorry. Please work with > >> them to get those acks, and then I will be glad to apply the rest (after > >> you resend them of course...) > >> > > > > On a second thought, I think zsmalloc should stay in drivers/block/zram > > since zram is now the only user of zsmalloc since zcache and ramster are > > moving to another allocator. > > The removal of zsmalloc from zcache has not been agreed upon > yet. > > Dan _suggested_ removing zsmalloc as the persistent > allocator for zcache in favor of zbud to solve "flaws" in > zcache. However, zbud has large deficiencies. > > A zero-filled 4k page will compress with LZO to 103 bytes. > zbud can only store two compressed pages in each memory pool > page, resulting in 95% fragmentation (i.e. 95% of the memory > pool page goes unused). While this might not be a typical > case, it is the worst case and absolutely does happen. > > zbud's design also effectively limits the useful page > compression to 50%. If pages are compressed beyond that, the > added space savings is lost in memory pool fragmentation. > For example, if two pages compress to 30% of their original > size, those two pages take up 60% of the zbud memory pool > page, and 40% is lost to fragmentation because zbud can't > store anything in the remaining space. > > To say it another way, for every two page cache pages that > cleancache stores in zcache, zbud _must_ allocate a memory > pool page, regardless of how well those pages compress. > This reduces the efficiency of the page cache reclaim > mechanism by half. > > I have posted some work (zsmalloc shrinker interface, user > registered alloc/free functions for the zsmalloc memory > pool) that begins to make zsmalloc a suitable replacement > for zbud, but that work was put on hold until the path out > of staging was established. > > I'm hoping to continue this work once the code is in > mainline. While zbud has deficiencies, it doesn't prevent > zcache from having value as I have already demonstrated. > However, replacing zsmalloc with zbud would step backward > for the reasons mentioned above. What would be nice is having only one engine instead of two - and I believe that is what you and Dan are aiming at. Dan is looking at it from the perspective of re-engineering zcache to use an LRU for keeping track of pages and pushing those to the compression engine. And redoing the zbud engine a bit (I think, let me double-check the git tree he pointed out). > > I do not support the removal of zsmalloc from zcache. As > such, I think the zsmalloc code should remain independent. > > Seth > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Tue, Aug 14, 2012 at 12:39:25PM -0500, Seth Jennings wrote: On 08/14/2012 12:36 AM, Nitin Gupta wrote: On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. The removal of zsmalloc from zcache has not been agreed upon yet. nods Dan _suggested_ removing zsmalloc as the persistent allocator for zcache in favor of zbud to solve flaws in zcache. However, zbud has large deficiencies. A zero-filled 4k page will compress with LZO to 103 bytes. zbud can only store two compressed pages in each memory pool page, resulting in 95% fragmentation (i.e. 95% of the memory pool page goes unused). While this might not be a typical case, it is the worst case and absolutely does happen. zbud's design also effectively limits the useful page compression to 50%. If pages are compressed beyond that, the added space savings is lost in memory pool fragmentation. For example, if two pages compress to 30% of their original size, those two pages take up 60% of the zbud memory pool page, and 40% is lost to fragmentation because zbud can't store anything in the remaining space. To say it another way, for every two page cache pages that cleancache stores in zcache, zbud _must_ allocate a memory pool page, regardless of how well those pages compress. This reduces the efficiency of the page cache reclaim mechanism by half. I have posted some work (zsmalloc shrinker interface, user registered alloc/free functions for the zsmalloc memory pool) that begins to make zsmalloc a suitable replacement for zbud, but that work was put on hold until the path out of staging was established. I'm hoping to continue this work once the code is in mainline. While zbud has deficiencies, it doesn't prevent zcache from having value as I have already demonstrated. However, replacing zsmalloc with zbud would step backward for the reasons mentioned above. What would be nice is having only one engine instead of two - and I believe that is what you and Dan are aiming at. Dan is looking at it from the perspective of re-engineering zcache to use an LRU for keeping track of pages and pushing those to the compression engine. And redoing the zbud engine a bit (I think, let me double-check the git tree he pointed out). I do not support the removal of zsmalloc from zcache. As such, I think the zsmalloc code should remain independent. Seth -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/7] zram/zsmalloc promotion
On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. The removal of zsmalloc from zcache has not been agreed upon yet. Dan _suggested_ removing zsmalloc as the persistent allocator for zcache in favor of zbud to solve flaws in zcache. (Correction: Dan has _coded_, _tested_ and _published_ _working_ code that removes zsmalloc ;-) However, zbud has large deficiencies. A zero-filled 4k page will compress with LZO to 103 bytes. zbud can only store two compressed pages in each memory pool page, resulting in 95% fragmentation (i.e. 95% of the memory pool page goes unused). While this might not be a typical case, it is the worst case and absolutely does happen. zbud's design also effectively limits the useful page compression to 50%. If pages are compressed beyond that, the added space savings is lost in memory pool fragmentation. For example, if two pages compress to 30% of their original size, those two pages take up 60% of the zbud memory pool page, and 40% is lost to fragmentation because zbud can't store anything in the remaining space. To say it another way, for every two page cache pages that cleancache stores in zcache, zbud _must_ allocate a memory pool page, regardless of how well those pages compress. This reduces the efficiency of the page cache reclaim mechanism by half. All very true, but these are not zbud deficiencies. They are design choices to ensure predictability so that pageframes can be reclaimed when the cache gets full. NOT zpages but complete pageframes, since this is what the rest of the kernel uses. And zbud handles LRU ordering also. Basic computer science principles tell us that maximizing storage density (as zsmalloc does) has major negative consequences especially when random fragments are freed, as is true for the random frontswap access patterns. You don't get higher density without much higher complexity. This is a fundamental design tradeoff for zcache. I have posted some work (zsmalloc shrinker interface, user registered alloc/free functions for the zsmalloc memory pool) that begins to make zsmalloc a suitable replacement for zbud, but that work was put on hold until the path out of staging was established. I'm hoping to continue this work once the code is in mainline. While zbud has deficiencies, it doesn't prevent zcache from having value as I have already demonstrated. However, replacing zsmalloc with zbud would step backward for the reasons mentioned above. Please do continue this work. But there was no indication that you had even begun to think through all the consequences of concurrent access or LRU pageframe reclaim. I did think through them and concluded that the issues were far more complex with zsmalloc than zbud (and would be happy to explain further). So I solved the issues with zbud and got both parts of zcache (frontswap and cleancache) working fully with zbud. In other words, IMHO the existing zsmalloc will need to evolve a great deal to work with the complete needs of zcache. If you can get both maximal density AND concurrency AND LRU pageframe reclaim all working with zsmalloc, and fully test it (with zcache) and publish it, I would support moving to this new zsmalloc instantly. I do not support the removal of zsmalloc from zcache. As such, I think the zsmalloc code should remain independent. Zcache must move forward to meet the needs of a broader set of workloads and distros and users, not just the limited toy benchmarking you have provided. Zsmalloc has not yet proven capable of meeting those needs. It may be capable in the future but it cannot meet them now. Dan P.S. I think zsmalloc IS a good match for zram so I do not object to the promotion of zsmalloc as part of promoting zram. Would be happy to explain technical details further if this surprises anyone. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/14/2012 12:36 AM, Nitin Gupta wrote: > On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: >> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: >>> This patchset promotes zram/zsmalloc from staging. >>> Both are very clean and zram is used by many embedded product >>> for a long time. >>> >>> [1-3] are patches not merged into linux-next yet but needed >>> it as base for [4-5] which promotes zsmalloc. >>> Greg, if you merged [1-3] already, skip them. >> >> I've applied 1-3 and now 4, but that's it, I can't apply the rest >> without getting acks from the -mm maintainers, sorry. Please work with >> them to get those acks, and then I will be glad to apply the rest (after >> you resend them of course...) >> > > On a second thought, I think zsmalloc should stay in drivers/block/zram > since zram is now the only user of zsmalloc since zcache and ramster are > moving to another allocator. The removal of zsmalloc from zcache has not been agreed upon yet. Dan _suggested_ removing zsmalloc as the persistent allocator for zcache in favor of zbud to solve "flaws" in zcache. However, zbud has large deficiencies. A zero-filled 4k page will compress with LZO to 103 bytes. zbud can only store two compressed pages in each memory pool page, resulting in 95% fragmentation (i.e. 95% of the memory pool page goes unused). While this might not be a typical case, it is the worst case and absolutely does happen. zbud's design also effectively limits the useful page compression to 50%. If pages are compressed beyond that, the added space savings is lost in memory pool fragmentation. For example, if two pages compress to 30% of their original size, those two pages take up 60% of the zbud memory pool page, and 40% is lost to fragmentation because zbud can't store anything in the remaining space. To say it another way, for every two page cache pages that cleancache stores in zcache, zbud _must_ allocate a memory pool page, regardless of how well those pages compress. This reduces the efficiency of the page cache reclaim mechanism by half. I have posted some work (zsmalloc shrinker interface, user registered alloc/free functions for the zsmalloc memory pool) that begins to make zsmalloc a suitable replacement for zbud, but that work was put on hold until the path out of staging was established. I'm hoping to continue this work once the code is in mainline. While zbud has deficiencies, it doesn't prevent zcache from having value as I have already demonstrated. However, replacing zsmalloc with zbud would step backward for the reasons mentioned above. I do not support the removal of zsmalloc from zcache. As such, I think the zsmalloc code should remain independent. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Tue, Aug 14, 2012 at 03:22:47PM +0900, Minchan Kim wrote: > Hi Greg, > > On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: > > On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > > > This patchset promotes zram/zsmalloc from staging. > > > Both are very clean and zram is used by many embedded product > > > for a long time. > > > > > > [1-3] are patches not merged into linux-next yet but needed > > > it as base for [4-5] which promotes zsmalloc. > > > Greg, if you merged [1-3] already, skip them. > > > > I've applied 1-3 and now 4, but that's it, I can't apply the rest > > Thanks! > > > without getting acks from the -mm maintainers, sorry. Please work with > > Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want > to confirm it from akpm so let's wait his opinion. > > Anyway, another question. zram would be under driver/blocks. > Do I need ACK from Jens for that? Yes. > > > them to get those acks, and then I will be glad to apply the rest (after > > you resend them of course...) > > > > thanks, > > > > greg k-h > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-mm' in > > the body to majord...@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > > -- > Kind regards, > Minchan Kim > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
Hi Greg, On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: > On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > > This patchset promotes zram/zsmalloc from staging. > > Both are very clean and zram is used by many embedded product > > for a long time. > > > > [1-3] are patches not merged into linux-next yet but needed > > it as base for [4-5] which promotes zsmalloc. > > Greg, if you merged [1-3] already, skip them. > > I've applied 1-3 and now 4, but that's it, I can't apply the rest Thanks! > without getting acks from the -mm maintainers, sorry. Please work with Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want to confirm it from akpm so let's wait his opinion. Anyway, another question. zram would be under driver/blocks. Do I need ACK from Jens for that? > them to get those acks, and then I will be glad to apply the rest (after > you resend them of course...) > > thanks, > > greg k-h > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
Hi Nitin, On Mon, Aug 13, 2012 at 10:36:47PM -0700, Nitin Gupta wrote: > On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > >> This patchset promotes zram/zsmalloc from staging. > >> Both are very clean and zram is used by many embedded product > >> for a long time. > >> > >> [1-3] are patches not merged into linux-next yet but needed > >> it as base for [4-5] which promotes zsmalloc. > >> Greg, if you merged [1-3] already, skip them. > > > > I've applied 1-3 and now 4, but that's it, I can't apply the rest > > without getting acks from the -mm maintainers, sorry. Please work with > > them to get those acks, and then I will be glad to apply the rest (after > > you resend them of course...) > > > > On a second thought, I think zsmalloc should stay in drivers/block/zram > since zram is now the only user of zsmalloc since zcache and ramster are > moving to another allocator. Secondly, zsmalloc does not provide > standard slab like interface, so should not be part of mm/. At the best, > it could be moved to lib/ with header in include/linux just like genalloc. I don't care whether it's located in /mm or wherever. But if we move it into out of /mm, I would like to confirm it from akpm. AFAIRC, he had a concern about that because zsmalloc used a few fields of struct page freely so he wanted to locate it in /mm. Andrew, Any thought? >-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
Hi Nitin, On Mon, Aug 13, 2012 at 10:36:47PM -0700, Nitin Gupta wrote: On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. Secondly, zsmalloc does not provide standard slab like interface, so should not be part of mm/. At the best, it could be moved to lib/ with header in include/linux just like genalloc. I don't care whether it's located in /mm or wherever. But if we move it into out of /mm, I would like to confirm it from akpm. AFAIRC, he had a concern about that because zsmalloc used a few fields of struct page freely so he wanted to locate it in /mm. Andrew, Any thought? -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
Hi Greg, On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest Thanks! without getting acks from the -mm maintainers, sorry. Please work with Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want to confirm it from akpm so let's wait his opinion. Anyway, another question. zram would be under driver/blocks. Do I need ACK from Jens for that? them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) thanks, greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Tue, Aug 14, 2012 at 03:22:47PM +0900, Minchan Kim wrote: Hi Greg, On Mon, Aug 13, 2012 at 07:35:30PM -0700, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest Thanks! without getting acks from the -mm maintainers, sorry. Please work with Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want to confirm it from akpm so let's wait his opinion. Anyway, another question. zram would be under driver/blocks. Do I need ACK from Jens for that? Yes. them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) thanks, greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/14/2012 12:36 AM, Nitin Gupta wrote: On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. The removal of zsmalloc from zcache has not been agreed upon yet. Dan _suggested_ removing zsmalloc as the persistent allocator for zcache in favor of zbud to solve flaws in zcache. However, zbud has large deficiencies. A zero-filled 4k page will compress with LZO to 103 bytes. zbud can only store two compressed pages in each memory pool page, resulting in 95% fragmentation (i.e. 95% of the memory pool page goes unused). While this might not be a typical case, it is the worst case and absolutely does happen. zbud's design also effectively limits the useful page compression to 50%. If pages are compressed beyond that, the added space savings is lost in memory pool fragmentation. For example, if two pages compress to 30% of their original size, those two pages take up 60% of the zbud memory pool page, and 40% is lost to fragmentation because zbud can't store anything in the remaining space. To say it another way, for every two page cache pages that cleancache stores in zcache, zbud _must_ allocate a memory pool page, regardless of how well those pages compress. This reduces the efficiency of the page cache reclaim mechanism by half. I have posted some work (zsmalloc shrinker interface, user registered alloc/free functions for the zsmalloc memory pool) that begins to make zsmalloc a suitable replacement for zbud, but that work was put on hold until the path out of staging was established. I'm hoping to continue this work once the code is in mainline. While zbud has deficiencies, it doesn't prevent zcache from having value as I have already demonstrated. However, replacing zsmalloc with zbud would step backward for the reasons mentioned above. I do not support the removal of zsmalloc from zcache. As such, I think the zsmalloc code should remain independent. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: > On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: >> This patchset promotes zram/zsmalloc from staging. >> Both are very clean and zram is used by many embedded product >> for a long time. >> >> [1-3] are patches not merged into linux-next yet but needed >> it as base for [4-5] which promotes zsmalloc. >> Greg, if you merged [1-3] already, skip them. > > I've applied 1-3 and now 4, but that's it, I can't apply the rest > without getting acks from the -mm maintainers, sorry. Please work with > them to get those acks, and then I will be glad to apply the rest (after > you resend them of course...) > On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. Secondly, zsmalloc does not provide standard slab like interface, so should not be part of mm/. At the best, it could be moved to lib/ with header in include/linux just like genalloc. Thanks, Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: > This patchset promotes zram/zsmalloc from staging. > Both are very clean and zram is used by many embedded product > for a long time. > > [1-3] are patches not merged into linux-next yet but needed > it as base for [4-5] which promotes zsmalloc. > Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. I've applied 1-3 and now 4, but that's it, I can't apply the rest without getting acks from the -mm maintainers, sorry. Please work with them to get those acks, and then I will be glad to apply the rest (after you resend them of course...) On a second thought, I think zsmalloc should stay in drivers/block/zram since zram is now the only user of zsmalloc since zcache and ramster are moving to another allocator. Secondly, zsmalloc does not provide standard slab like interface, so should not be part of mm/. At the best, it could be moved to lib/ with header in include/linux just like genalloc. Thanks, Nitin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Wed, Aug 08, 2012 at 10:35:37AM -0700, Nitin Gupta wrote: > On 08/07/2012 11:12 PM, Minchan Kim wrote: > > This patchset promotes zram/zsmalloc from staging. > > Both are very clean and zram is used by many embedded product > > for a long time. > > > > [1-3] are patches not merged into linux-next yet but needed > > it as base for [4-5] which promotes zsmalloc. > > Greg, if you merged [1-3] already, skip them. > > > > Seth Jennings (5): > > 1. zsmalloc: s/firstpage/page in new copy map funcs > > 2. zsmalloc: prevent mappping in interrupt context > > 3. zsmalloc: add page table mapping method > > 4. zsmalloc: collapse internal .h into .c > > 5. zsmalloc: promote to mm/ > > > > Minchan Kim (2): > > 6. zram: promote zram from staging > > 7. zram: select ZSMALLOC when ZRAM is configured > > > > All the changes look good to me. FWIW, for the entire series: > Acked-by: Nitin Gupta And Reviewed-by: Konrad Rzeszutek Wilk as well. Thanks! > > Thanks for all the work. > Nitin > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Wed, Aug 08, 2012 at 10:35:37AM -0700, Nitin Gupta wrote: On 08/07/2012 11:12 PM, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. Seth Jennings (5): 1. zsmalloc: s/firstpage/page in new copy map funcs 2. zsmalloc: prevent mappping in interrupt context 3. zsmalloc: add page table mapping method 4. zsmalloc: collapse internal .h into .c 5. zsmalloc: promote to mm/ Minchan Kim (2): 6. zram: promote zram from staging 7. zram: select ZSMALLOC when ZRAM is configured All the changes look good to me. FWIW, for the entire series: Acked-by: Nitin Gupta ngu...@vflare.org And Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com as well. Thanks! Thanks for all the work. Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/07/2012 11:12 PM, Minchan Kim wrote: > This patchset promotes zram/zsmalloc from staging. > Both are very clean and zram is used by many embedded product > for a long time. > > [1-3] are patches not merged into linux-next yet but needed > it as base for [4-5] which promotes zsmalloc. > Greg, if you merged [1-3] already, skip them. > > Seth Jennings (5): > 1. zsmalloc: s/firstpage/page in new copy map funcs > 2. zsmalloc: prevent mappping in interrupt context > 3. zsmalloc: add page table mapping method > 4. zsmalloc: collapse internal .h into .c > 5. zsmalloc: promote to mm/ > > Minchan Kim (2): > 6. zram: promote zram from staging > 7. zram: select ZSMALLOC when ZRAM is configured > All the changes look good to me. FWIW, for the entire series: Acked-by: Nitin Gupta Thanks for all the work. Nitin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] zram/zsmalloc promotion
This patchset promotes zram/zsmalloc from staging.
Both are very clean and zram is used by many embedded product
for a long time.
[1-3] are patches not merged into linux-next yet but needed
it as base for [4-5] which promotes zsmalloc.
Greg, if you merged [1-3] already, skip them.
Seth Jennings (5):
1. zsmalloc: s/firstpage/page in new copy map funcs
2. zsmalloc: prevent mappping in interrupt context
3. zsmalloc: add page table mapping method
4. zsmalloc: collapse internal .h into .c
5. zsmalloc: promote to mm/
Minchan Kim (2):
6. zram: promote zram from staging
7. zram: select ZSMALLOC when ZRAM is configured
drivers/block/Kconfig |1 +
drivers/block/Makefile |1 +
drivers/{staging => block}/zram/Kconfig|3 +-
drivers/{staging => block}/zram/Makefile |0
drivers/{staging => block}/zram/zram.txt |0
drivers/{staging => block}/zram/zram_drv.c |0
drivers/{staging => block}/zram/zram_drv.h |3 +-
drivers/{staging => block}/zram/zram_sysfs.c |0
drivers/staging/Kconfig|4 -
drivers/staging/Makefile |2 -
drivers/staging/zcache/zcache-main.c |4 +-
drivers/staging/zsmalloc/Kconfig | 10 -
drivers/staging/zsmalloc/Makefile |3 -
drivers/staging/zsmalloc/zsmalloc_int.h| 155 --
.../staging/zsmalloc => include/linux}/zsmalloc.h |0
mm/Kconfig | 18 ++
mm/Makefile|1 +
.../zsmalloc/zsmalloc-main.c => mm/zsmalloc.c | 323 +---
18 files changed, 299 insertions(+), 229 deletions(-)
rename drivers/{staging => block}/zram/Kconfig (94%)
rename drivers/{staging => block}/zram/Makefile (100%)
rename drivers/{staging => block}/zram/zram.txt (100%)
rename drivers/{staging => block}/zram/zram_drv.c (100%)
rename drivers/{staging => block}/zram/zram_drv.h (98%)
rename drivers/{staging => block}/zram/zram_sysfs.c (100%)
delete mode 100644 drivers/staging/zsmalloc/Kconfig
delete mode 100644 drivers/staging/zsmalloc/Makefile
delete mode 100644 drivers/staging/zsmalloc/zsmalloc_int.h
rename {drivers/staging/zsmalloc => include/linux}/zsmalloc.h (100%)
rename drivers/staging/zsmalloc/zsmalloc-main.c => mm/zsmalloc.c (73%)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] zram/zsmalloc promotion
This patchset promotes zram/zsmalloc from staging.
Both are very clean and zram is used by many embedded product
for a long time.
[1-3] are patches not merged into linux-next yet but needed
it as base for [4-5] which promotes zsmalloc.
Greg, if you merged [1-3] already, skip them.
Seth Jennings (5):
1. zsmalloc: s/firstpage/page in new copy map funcs
2. zsmalloc: prevent mappping in interrupt context
3. zsmalloc: add page table mapping method
4. zsmalloc: collapse internal .h into .c
5. zsmalloc: promote to mm/
Minchan Kim (2):
6. zram: promote zram from staging
7. zram: select ZSMALLOC when ZRAM is configured
drivers/block/Kconfig |1 +
drivers/block/Makefile |1 +
drivers/{staging = block}/zram/Kconfig|3 +-
drivers/{staging = block}/zram/Makefile |0
drivers/{staging = block}/zram/zram.txt |0
drivers/{staging = block}/zram/zram_drv.c |0
drivers/{staging = block}/zram/zram_drv.h |3 +-
drivers/{staging = block}/zram/zram_sysfs.c |0
drivers/staging/Kconfig|4 -
drivers/staging/Makefile |2 -
drivers/staging/zcache/zcache-main.c |4 +-
drivers/staging/zsmalloc/Kconfig | 10 -
drivers/staging/zsmalloc/Makefile |3 -
drivers/staging/zsmalloc/zsmalloc_int.h| 155 --
.../staging/zsmalloc = include/linux}/zsmalloc.h |0
mm/Kconfig | 18 ++
mm/Makefile|1 +
.../zsmalloc/zsmalloc-main.c = mm/zsmalloc.c | 323 +---
18 files changed, 299 insertions(+), 229 deletions(-)
rename drivers/{staging = block}/zram/Kconfig (94%)
rename drivers/{staging = block}/zram/Makefile (100%)
rename drivers/{staging = block}/zram/zram.txt (100%)
rename drivers/{staging = block}/zram/zram_drv.c (100%)
rename drivers/{staging = block}/zram/zram_drv.h (98%)
rename drivers/{staging = block}/zram/zram_sysfs.c (100%)
delete mode 100644 drivers/staging/zsmalloc/Kconfig
delete mode 100644 drivers/staging/zsmalloc/Makefile
delete mode 100644 drivers/staging/zsmalloc/zsmalloc_int.h
rename {drivers/staging/zsmalloc = include/linux}/zsmalloc.h (100%)
rename drivers/staging/zsmalloc/zsmalloc-main.c = mm/zsmalloc.c (73%)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On 08/07/2012 11:12 PM, Minchan Kim wrote: This patchset promotes zram/zsmalloc from staging. Both are very clean and zram is used by many embedded product for a long time. [1-3] are patches not merged into linux-next yet but needed it as base for [4-5] which promotes zsmalloc. Greg, if you merged [1-3] already, skip them. Seth Jennings (5): 1. zsmalloc: s/firstpage/page in new copy map funcs 2. zsmalloc: prevent mappping in interrupt context 3. zsmalloc: add page table mapping method 4. zsmalloc: collapse internal .h into .c 5. zsmalloc: promote to mm/ Minchan Kim (2): 6. zram: promote zram from staging 7. zram: select ZSMALLOC when ZRAM is configured All the changes look good to me. FWIW, for the entire series: Acked-by: Nitin Gupta ngu...@vflare.org Thanks for all the work. Nitin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
