All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Kyeongdon Kim <kyeongdon.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	ngupta@vflare.org, linux-kernel@vger.kernel.org,
	sergey.senozhatsky@gmail.com
Subject: Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc
Date: Mon, 23 Nov 2015 16:43:37 +0900	[thread overview]
Message-ID: <20151123074337.GD7449@swordfish> (raw)
In-Reply-To: <20151123041847.GA23030@blaptop>

On (11/23/15 13:18), Minchan Kim wrote:
[..]
> > https://lkml.org/lkml/2015/6/16/465
> 
> Sorry, I have missed that.
> It's worth to fix that you proved it that could happen.
> But when I read your patch, GFP_NOIO instead GFP_NOFS would
> better way. Could you resend it?

no problem.

agree. we also would want to switch from vzalloc() to
	__vmalloc_node_flags(size, NUMA_NO_NODE,
			GFP_NOIO | __GFP_HIGHMEM |  __GFP_ZERO)

in fallbacks. I'll send the patch later today.

> > 
> > > If it is true, we should fix several allocation flags in
> > > zcomp_strm_alloc. I just want to record this warning for the future
> > > in this thread so someone who is finding for the contribution
> > > material will prove and fix it. :)
> > 
> > I can re-send the patch.
> > 
> > And, in case if you missed it, what's your opinion on the idea of
> > reducing ->max_strm if we can't allocate new streams. Here:
> > http://marc.info/?l=linux-kernel&m=144798049429861
> 
> Hmm, auto backoff max_comp_streams with warn to user, I'm not sure
> we really need it. Alloc failure is depenent on the workload and
> timing so although there are a fail in t1, it could be successful
> in t2 so if we *really* want to introduce auto backoff, the logic
> should include advance routine as well as backoff. With that,
> I want to handle it traparently without notice to user.

yes. auto roll-back is important (that's why I mentioned it). the idea
is to avoid stealing of pages for streams. for example, in case of low
memory decrease ->max_strm to
	MAX(->avail_strm, ->max_strm, online cpus() / 2)

and even probably release some idle streams (um... as a reaction
to shrinker call???). or at least prevent setting of ->max_sgtrm to
some unreasonably huge values... "> 4 * NR_CPUS", for instance. but
this is not so critical.

> So, Kyeongdon's patch will remove warning overhead and likely to
> make zcomp_stram_alloc successful with vmalloc so I want to
> roll it out first. And let's add a WARN_ON_ONCE to detect of
> failure and rethink it when we receive such report.

	-ss

  reply	other threads:[~2015-11-23  7:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23  4:18 [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc Minchan Kim
2015-11-23  7:43 ` Sergey Senozhatsky [this message]
2015-11-23  8:13   ` Sergey Senozhatsky
  -- strict thread matches above, loose matches on Subject: below --
2015-11-20 10:02 Kyeongdon Kim
2015-11-21  2:10 ` Sergey Senozhatsky
2015-11-21  2:15   ` Sergey Senozhatsky
2015-11-21  9:37     ` Sergey Senozhatsky
2015-11-23  2:15 ` Minchan Kim
2015-11-23  3:14   ` Sergey Senozhatsky
2015-11-23  3:35     ` Sergey Senozhatsky

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=20151123074337.GD7449@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=ngupta@vflare.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.