From: Uladzislau Rezki <urezki@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Uladzislau Rezki <urezki@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Matthew Wilcox <willy@infradead.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [PATCH 1/1] rcu/tree: Drop the lock before entering to page allocator
Date: Thu, 16 Jul 2020 16:47:28 +0200 [thread overview]
Message-ID: <20200716144728.GA31046@pc636> (raw)
In-Reply-To: <20200716142537.ecp4icsq7kg6qhdx@linutronix.de>
On Thu, Jul 16, 2020 at 04:25:37PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-07-16 11:19:13 [+0200], Uladzislau Rezki wrote:
> > Sebastian, could you please confirm that if that patch that is in
> > question fixes it?
> >
> > It would be appreciated!
>
> So that preempt disable should in terms any warnings. However I don't
> think that it is strictly needed and from scheduling point of view you
> forbid a CPU migration which might be good otherwise.
>
Please elaborate your point regarding "i do not think it is strictly needed".
Actually i can rework the patch to remove even such preempt_enable/disable
to stay on the same CPU, but i do not see the point of doing it.
Do you see the point?
As for scheduling point of view. Well, there are many places when there
is a demand in memory or pages from atomic context. Also, getting a page
is not considered as a hot path in the kfree_rcu().
>
> Also if interrupts and everything is enabled then someone else might
> invoke kfree_rcu() from BH context for instance.
>
And what? What is a problem here, please elaborate if you see any
issues.
--
Vlad Rezki
next prev parent reply other threads:[~2020-07-16 14:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 18:35 [PATCH 1/1] rcu/tree: Drop the lock before entering to page allocator Uladzislau Rezki (Sony)
2020-07-15 18:56 ` Sebastian Andrzej Siewior
2020-07-15 19:02 ` Uladzislau Rezki
2020-07-15 19:32 ` Sebastian Andrzej Siewior
2020-07-15 19:36 ` Uladzislau Rezki
2020-07-15 22:14 ` Paul E. McKenney
2020-07-16 14:14 ` Sebastian Andrzej Siewior
2020-07-16 15:20 ` Paul E. McKenney
2020-07-16 15:36 ` Sebastian Andrzej Siewior
2020-07-16 16:36 ` Paul E. McKenney
2020-07-15 23:13 ` Joel Fernandes
2020-07-16 9:19 ` Uladzislau Rezki
2020-07-16 13:36 ` Joel Fernandes
2020-07-16 14:37 ` Uladzislau Rezki
2020-07-16 18:27 ` Joel Fernandes
2020-07-16 19:03 ` Uladzislau Rezki
2020-07-16 14:25 ` Sebastian Andrzej Siewior
2020-07-16 14:47 ` Uladzislau Rezki [this message]
2020-07-16 15:04 ` Sebastian Andrzej Siewior
2020-07-16 15:34 ` Uladzislau Rezki
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=20200716144728.GA31046@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.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.