Re: [PATCH v3] zram: try vmalloc() after kmalloc()

[Sergey Senozhatsky]

On (11/24/15 09:35), Minchan Kim wrote:
[..]
> > We can use __GFP_RECLAIM (used to be __GFP_WAIT).  That permits the
> > allocation to wait for in-flight IO to complete and to reclaim clean
> > pagecache.
> 
> Generally, you're right but in case of zram, it would be unfortunate.
> 
> It would be void *most of time* because it is called in reclaim context
> and reclaim path bails out to avoid recursion of direct reclaim
> by PF_MEMALLOC without trying reclaim.
> However, the reason I said *most of time* is we has another context
> the funcion could be called.
> 
>         "disksize_store"->zcomp_create
> 
> In the place, we should make sure the successful allocation to work
> zram at least so that path should use another gfp.
> I will work for that.

Hm... is it really worth it? passing a bool to zcomp_strm_alloc() (so
it can decide what gfp flags to use) or gfp flags directly is just a
bit complicated. what's the problem with GFP_NOIO (__GFP_RECLAIM) in
the first place (sorry if I'm missing something terribly obvious)?

alternatively, we can just remove the 'dynamic' streams allocation part
and allocate all of the streams via sysfs store path only.

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