From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kyeongdon Kim <kyeongdon.kim@lge.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] zram/zcomp: use GFP_NOIO to allocate streams
Date: Tue, 24 Nov 2015 13:41:39 +0900 [thread overview]
Message-ID: <20151124044139.GF705@swordfish> (raw)
In-Reply-To: <20151124041341.GB11115@blaptop>
On (11/24/15 13:13), Minchan Kim wrote:
> First of all, Thanks for the summary and proposal.
sure :)
> I think GFP_NOIO critical part(ie, your lockdep fix patch) should
> go to -stable so it should stand alone.
>
> About vmalloc, I like that. Just problem was gfp and we can
> pass it from upper layer so I believe it makes code looks clean
> and solve differnt gfp problem.
doing vmalloc() after kmalloc in general looks ok, but the thing is that
kmalloc()->vmalloc() fallback does not mean that stream allocation will
end up being successful, because right after ->private we need to allocate
->buffer via __get_free_pages() and that thing can fail. so trying harder
in comp->backend->create() is just half of what we need.
but the question is -- do we have a really big reason to fallback in
->private allocation? we are quite prepared to handle that allocation
failure and I tend to think that in low memory condition it's probably
better to avoid stealing pages for additional streams; one stream is
just enough, if we are lucky to have more than one stream by that time
-- then fine.
> Please look at my patchset I just sent.
I'll take a look once I receive them (not in my inbox yet).
-ss
next prev parent reply other threads:[~2015-11-24 4:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 13:27 [PATCH] zram/zcomp: use GFP_NOIO to allocate streams Sergey Senozhatsky
2015-11-23 23:18 ` Andrew Morton
2015-11-24 0:30 ` Sergey Senozhatsky
2015-11-24 0:47 ` Andrew Morton
2015-11-24 1:29 ` Sergey Senozhatsky
2015-11-24 4:13 ` Minchan Kim
2015-11-24 4:41 ` Sergey Senozhatsky [this message]
2015-11-23 23:23 ` Minchan Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151124044139.GF705@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=kyeongdon.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.