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

From	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v3] zram: try vmalloc() after kmalloc()
Date	2015-11-24 02:10 +0100
Message-ID	<qyahk-1bG-5@gated-at.bofh.it> (permalink)
References	<qxSNr-6uY-3@gated-at.bofh.it> <qy8fv-89o-9@gated-at.bofh.it> <qy8Iy-6V-11@gated-at.bofh.it> <qy91T-dn-3@gated-at.bofh.it> <qy9Oh-Lz-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

[PATCH v3] zram: try vmalloc() after kmalloc() Kyeongdon Kim <kyeongdon.kim@lge.com> - 2015-11-23 07:30 +0100
  Re: [PATCH v3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-23 07:40 +0100
    Re: [PATCH v3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-23 08:30 +0100
  Re: [PATCH v3] zram: try vmalloc() after kmalloc() Andrew Morton <akpm@linux-foundation.org> - 2015-11-24 00:00 +0100
    Re: [PATCH v3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 00:30 +0100
      Re: [PATCH v3] zram: try vmalloc() after kmalloc() Andrew Morton <akpm@linux-foundation.org> - 2015-11-24 00:50 +0100
        Re: [PATCH v3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 01:40 +0100
          Re: [PATCH v3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 02:10 +0100
            Re: [PATCH v3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 05:00 +0100
      Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc() Kyeongdon Kim <kyeongdon.kim@lge.com> - 2015-11-24 09:10 +0100
        Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 09:20 +0100
    Re: Re: [PATCH v3] zram: try vmalloc() after kmalloc() Kyeongdon Kim <kyeongdon.kim@lge.com> - 2015-11-24 09:00 +0100

csiph-web