All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH RFC] rcu/tree: Refactor object allocation and try harder for array allocation
Date: Tue, 5 May 2020 20:33:17 +0200	[thread overview]
Message-ID: <20200505183317.GA28175@pc636> (raw)
In-Reply-To: <20200505181743.GA109369@cmpxchg.org>

> > b) Double argument(with rcu_head)
> > This case we consider as it gets called from atomic context even though
> > it can be not. Why we consider such case as atomic: we just assume that.
> > The reason is to keep it simple, because it is not possible to detect whether
> > a current context is attomic or not(for all type of kernels), i mean the one
> > that calls kfree_rcu().
> > 
> > In this case we do not have synchronize_rcu() option. Instead we have an
> > object with rcu_head inside. If an allocation gets failed we just make
> > use of rcu_head inside the object, regular queuing.
> > 
> > In this case we do not need to hard in order to obtain memory. Therefore
> > my question was to Johannes what is best way here. Since we decided to
> > minimize reclaiming, whereas GFP_NOWAIT wakes up kswapd if no memory.
> > GFP_ATOMIC also is not good, because for (b) we do not need to waste
> > it.
> 
> Waking kswapd is fine, because it's a shared facility that doesn't
> just reclaim on your behalf but on behalf of a central goal: to get
> the freelist back to the watermarks. If they're low, somebody will
> sooner or later kick kswapd anyway to do exactly that.
> 
> So unless you ask kswapd for a high order page that is unlikely to be
> needed by anybody else, you're only doing the inevitable.
>
Johannes, thank you for the clarification!

--
Vlad Rezki

      reply	other threads:[~2020-05-05 18:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 21:15 [PATCH RFC] rcu/tree: Refactor object allocation and try harder for array allocation Joel Fernandes (Google)
2020-04-14 19:43 ` Paul E. McKenney
2020-04-16 10:30   ` Uladzislau Rezki
2020-04-16 13:17     ` Joel Fernandes
2020-04-16 18:01       ` Paul E. McKenney
2020-04-22 14:57         ` Johannes Weiner
2020-04-22 15:35           ` Paul E. McKenney
2020-04-23 17:48             ` Johannes Weiner
2020-04-23 18:02               ` Paul E. McKenney
2020-04-23 18:27                 ` Uladzislau Rezki
2020-04-23 19:21                   ` Paul E. McKenney
2020-04-23 19:59                     ` Uladzislau Rezki
2020-04-24  4:16                       ` Joel Fernandes
2020-04-24 12:28                         ` Uladzislau Rezki
2020-05-05 18:17                       ` Johannes Weiner
2020-05-05 18:33                         ` Uladzislau Rezki [this message]

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=20200505183317.GA28175@pc636 \
    --to=urezki@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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.