Hi Sergey, On Wed, Nov 25, 2015 at 09:46:47PM +0900, Sergey Senozhatsky wrote: > On (11/25/15 14:51), Minchan Kim wrote: > [..] > > + /* > > + * This function could be called in swapout/fs write path > > + * so we couldn't use GFP_FS|IO. And it assumes we already > > + * have at least one stream in zram initialization so we > > + * don't do best effort to allocate more stream in here. > > + * A default stream will work well without further multiple > > + * stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC. > > + */ > > + zstrm = zcomp_strm_alloc(comp, GFP_NOIO|__GFP_NORETRY| > > + __GFP_NOWARN|__GFP_NOMEMALLOC); > [..] > > I think that applying 3/3 before 2/3 will be a simpler (and probably a better) > thing to do. We fitst extend zcomp interface and pass flags (without any > functional change) and then extend the flags and introduce vmalloc fallback.
The reason I ordered such way is that I wanted to discuss [2/3] as stable material after I get your ACK. It solves real problem in android platform which is real fact and I think it's enough small to send stable tree. What do you think? > > So we don't have to add comments to lz4/lzo backend that are getting > (re-)moved > in the very next commit. Fair enough if you don't agree sending [2/3] to stable. > > I will send swapped 2 and 3 patches shortly (I didn't change commit > messages and SoBs). Please take a look. Thanks! > > > - /* > > - * This function could be called in swapout/fs write path > > - * so we couldn't use GFP_FS|IO. And it assumes we already > > - * have at least one stream in zram initialization so we > > - * don't do best effort to allocate more stream in here. > > - * A default stream will work well without further multiple > > - * stream. That's why we use __GFP_NORETRY|NOWARN|NOMEMALLOC. > > - */ > > - ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > > - __GFP_NOWARN|__GFP_NOMEMALLOC); > > + ret = kmalloc(LZ4_MEM_COMPRESS, flags); > > if (!ret) > > - ret = __vmalloc(LZ4_MEM_COMPRESS, GFP_NOIO|__GFP_NORETRY| > > - __GFP_NOWARN|__GFP_NOMEMALLOC| > > - __GFP_ZERO, > > - PAGE_KERNEL); > > + ret = __vmalloc(LZ4_MEM_COMPRESS, flags, PAGE_KERNEL); > [..] > > __vmalloc() is still missing __GFP_HIGHMEM Argh, Sorry. -- 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/