On Sun, Jan 24, 2021 at 02:21:07AM +, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月22日 22:31
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki; Paul E. McKenney; r...@vger.kernel.org;
> linux-kernel@vger.kernel.
> On 2021-01-21 13:38:34 [+0100], Uladzislau Rezki wrote:
> > __get_free_page() returns "unsigned long" whereas a bnode is a pointer
> > to kvfree_rcu_bulk_data struct, without a casting the compiler will
> > emit a warning.
>
> Yes, learned about it,
On Fri, Jan 22, 2021 at 01:44:36AM +, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月22日 4:26
> 收件人: Zhang, Qiang
> 抄送: Paul E. McKenney; r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ure...@gmail.c
Hello, Qiang,
> On Thu, Jan 21, 2021 at 02:49:49PM +0800, qiang.zh...@windriver.com wrote:
> > From: Zqiang
> >
> > If CPUs go offline, the corresponding krcp's page cache can
> > not be use util the CPU come back online, or maybe the CPU
> > will never go online again, this commit therefore
On Thu, Jan 21, 2021 at 07:07:40AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 21, 2021 at 02:35:10PM +0100, Uladzislau Rezki wrote:
> > On Wed, Jan 20, 2021 at 01:54:03PM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian And
On Wed, Jan 20, 2021 at 01:54:03PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2021-01-20 17:21:46 [+0100], Uladzislau Rezki (Sony) wrote:
> > > For a single argument we can directly request a page from a ca
On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-20 17:21:46 [+0100], Uladzislau Rezki (Sony) wrote:
> > For a single argument we can directly request a page from a caller
> > context when a "carry page block" is run out of free spot
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index e04e336bee42..2014fb22644d 100644
--- a/kernel/rcu/tr
chal Hocko
Signed-off-by: Paul E. McKenney
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 2014fb22644d..454809514c91 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
() are now independent of RT, use it in order
to prevent any migration during a page request for a specific CPU it
is requested for.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index
riod.
> --
> 2.29.2
>
I think it is fair enough. I checked the "kernel-doc" and after this
change it does not detect any violations which are in question.
Tested-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
area->nr_pages = count;
> + }
> return area->addr;
> }
> EXPORT_SYMBOL(vmap);
> --
> 2.19.1
>
Reviewed-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
> On Tue, Jan 5, 2021 at 5:29 PM Uladzislau Rezki wrote:
> >
> > On Tue, Jan 05, 2021 at 06:56:59AM -0800, Paul E. McKenney wrote:
> > > On Tue, Jan 05, 2021 at 02:14:41PM +0100, Uladzislau Rezki wrote:
> > > > Dear, Lukas.
> > > >
> >
On Tue, Jan 05, 2021 at 06:56:59AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 05, 2021 at 02:14:41PM +0100, Uladzislau Rezki wrote:
> > Dear, Lukas.
> >
> > > Dear Uladzislau,
> > >
> > > in commit 538fc2ee870a3 ("rcu: Introduce kfree_rcu() sin
ion. I am not sure if htmldocs supports something
like "__maybe_unused", but tend to say that it does not. See below the
patch:
>From 65ecc7c58810c963c02e0596ce2e5758c54ef55d Mon Sep 17 00:00:00 2001
From: "Uladzislau Rezki (Sony)"
Date: Tue, 5 Jan 2021 13:23:30 +0100
Subject: [
On Mon, Dec 21, 2020 at 12:45:13PM -0800, Paul E. McKenney wrote:
> On Mon, Dec 21, 2020 at 08:48:48PM +0100, Uladzislau Rezki wrote:
> > On Mon, Dec 21, 2020 at 11:29:06AM -0800, Paul E. McKenney wrote:
> > > On Mon, Dec 21, 2020 at 07:45:39PM +0100, Uladzislau Rezki wrote:
>
On Mon, Dec 21, 2020 at 11:29:06AM -0800, Paul E. McKenney wrote:
> On Mon, Dec 21, 2020 at 07:45:39PM +0100, Uladzislau Rezki wrote:
> > On Mon, Dec 21, 2020 at 09:18:05AM -0800, Paul E. McKenney wrote:
> > > On Mon, Dec 21, 2020 at 04:38:09PM +0100, Uladzislau Rezki wrote:
>
On Wed, Dec 16, 2020 at 03:29:55PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 16, 2020 at 04:49:59PM +0100, Uladzislau Rezki wrote:
> > > Add self tests for checking of RCU-tasks API functionality.
> > > It covers:
> > > - wait API functions;
> > >
On Mon, Dec 21, 2020 at 09:18:05AM -0800, Paul E. McKenney wrote:
> On Mon, Dec 21, 2020 at 04:38:09PM +0100, Uladzislau Rezki wrote:
> > On Wed, Dec 16, 2020 at 03:29:55PM -0800, Paul E. McKenney wrote:
> > > On Wed, Dec 16, 2020 at 04:49:59PM +0100, Ulad
> Add self tests for checking of RCU-tasks API functionality.
> It covers:
> - wait API functions;
> - invoking/completion call_rcu_tasks*().
>
> Self-tests are run when CONFIG_PROVE_RCU kernel parameter is set.
>
> Signed-off-by: Uladzislau Rezki (Sony)
> ---
On Mon, Dec 14, 2020 at 03:37:46PM +, Matthew Wilcox wrote:
> On Mon, Dec 14, 2020 at 04:11:28PM +0100, Uladzislau Rezki wrote:
> > On Sun, Dec 13, 2020 at 09:51:34PM +, Matthew Wilcox wrote:
> > > If we need to iterate the list efficiently, i'd suggest getting rid
On Sun, Dec 13, 2020 at 09:51:34PM +, Matthew Wilcox wrote:
> On Sun, Dec 13, 2020 at 07:39:36PM +0100, Uladzislau Rezki wrote:
> > On Sun, Dec 13, 2020 at 01:08:43PM -0500, Waiman Long wrote:
> > > When multiple locks are acquired, they should be released in reverse
> &
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 56292e8609e39537297a7468dda4d87b9bd81d6a
Gitweb:
https://git.kernel.org/tip/56292e8609e39537297a7468dda4d87b9bd81d6a
Author:Uladzislau Rezki (Sony)
AuthorDate:Thu, 29 Oct 2020 17:50:04 +01:00
or example when there
are multiple heavy readers of /proc/vmallocinfo, i think, it make sense
to implement RCU safe lists iteration and get rid of both locks.
As for the patch: Reviewed-by: Uladzislau Rezki (Sony)
Thanks!
--
Vlad Rezki
Hello, Paul.
[Dropping CC]
> Hello, Joel,
>
> In case you are -seriously- interested... ;-)
>
> Thanx, Paul
>
> rcu_nocbs=
>
> Adding a CPU to this list offloads RCU callback invocation from
> that CPU's softirq handler to a kthread.
>> API in early_initcall() callbacks.
> >>
> >> Fixes: 36dadef23fcc ("kprobes: Init kprobes in early_initcall")
> >> Signed-off-by: Uladzislau Rezki (Sony)
>
> Tested-by: Daniel Axtens
>
Thank you for checking it!
> >> ---
> >> incl
On Wed, Dec 09, 2020 at 07:26:13PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 09, 2020 at 09:27:31PM +0100, Uladzislau Rezki (Sony) wrote:
> > Initialize the RCU-tasks earlier, before *_initcall() callbacks are
> > invoked. Do it after the workqueue subsytem is up and running. Th
t;kprobes: Init kprobes in early_initcall")
> Signed-off-by: Uladzislau Rezki (Sony)
> ---
> include/linux/rcupdate.h | 6 ++
> init/main.c | 1 +
> kernel/rcu/tasks.h | 26 ++
> 3 files changed, 29 insertions(+), 4 deletion
Add self tests for checking of RCU-tasks API functionality.
It covers:
- wait API functions;
- invoking/completion call_rcu_tasks*().
Self-tests are run when CONFIG_PROVE_RCU kernel parameter is set.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tasks.h | 44
robes in early_initcall")
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/rcupdate.h | 6 ++
init/main.c | 1 +
kernel/rcu/tasks.h | 26 ++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/
On Wed, Dec 09, 2020 at 11:42:39AM -0800, Paul E. McKenney wrote:
> On Wed, Dec 09, 2020 at 08:36:37PM +0100, Uladzislau Rezki wrote:
> > On Tue, Dec 08, 2020 at 05:13:01PM -0800, paul...@kernel.org wrote:
> > > From: "Paul E. McKenney"
> > >
>
On Wed, Dec 09, 2020 at 06:51:20PM +0100, Vlastimil Babka wrote:
> On 12/9/20 2:13 AM, paul...@kernel.org wrote:
> > From: "Paul E. McKenney"
> >
> > This commit adds vmalloc() support to mem_dump_obj(). Note that the
> > vmalloc_dump_obj() function combines the checking and dumping, in
> >
On Tue, Dec 08, 2020 at 05:13:01PM -0800, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> This commit adds vmalloc() support to mem_dump_obj(). Note that the
> vmalloc_dump_obj() function combines the checking and dumping, in
> contrast with the split between kmem_valid_obj() and
> On Thu, Nov 26, 2020 at 05:44:28PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the rcu tree, today's linux-next build (htmldocs) produced
> > these warnings:
> >
> > include/linux/rcupdate.h:872: warning: Excess function parameter 'ptr'
> > description in 'kfree_rcu'
> >
On Wed, Nov 25, 2020 at 08:52:58AM +0800, Huang, Ying wrote:
> Uladzislau Rezki writes:
> >> >> > - lazy_max_pages() can slightly be decreased. If there are existing
> >> >> > workloads which suffer from such long value. It would be good to ge
On Tue, Nov 24, 2020 at 11:55:51AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 20, 2020 at 12:49:17PM +0100, Uladzislau Rezki (Sony) wrote:
> > Make the kvfree_rcu_arg_2() to be open-coded, so readability
> > and review look better from the first glance. Moreover, that
>
> >> >>
> >> >> That's the typical long latency avoidance method.
> >> >>
> >> >> > The question is, which value we should use as a batch_threshold: 100,
> >> >> > 1000, etc.
> >> >>
> >> >> I think we can do some measurement to determine it?
> >> >>
> >> > Hmm.. looking at it one more time i
On Fri, Nov 20, 2020 at 10:34:19AM +0800, Huang, Ying wrote:
> Uladzislau Rezki writes:
>
> > On Thu, Nov 19, 2020 at 09:40:29AM +0800, Huang, Ying wrote:
> >> Uladzislau Rezki writes:
> >>
> >> > On Wed, Nov 18, 2020 at 10:44:13AM +0800, huang ying w
> On Fri, Nov 20, 2020 at 12:59 PM Uladzislau Rezki wrote:
> >
> > On Thu, Nov 19, 2020 at 01:49:34PM -0800, Paul E. McKenney wrote:
> > > On Wed, Nov 18, 2020 at 11:53:09AM +0800, qiang.zh...@windriver.com wrote:
> > > > From: Zqiang
> > >
On Thu, Nov 19, 2020 at 01:49:34PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 18, 2020 at 11:53:09AM +0800, qiang.zh...@windriver.com wrote:
> > From: Zqiang
> >
> > Add kasan_record_aux_stack function for kvfree_call_rcu function to
> > record call stacks.
> >
> > Signed-off-by: Zqiang
>
>
for users.
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/rcupdate.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e09c0d87b3c3..b1e75648d402 100644
--- a/include/linux/rcupdate.h
Make the kvfree_rcu_arg_2() to be open-coded, so readability
and review look better from the first glance. Moreover, that
makes it clear that both kvfree_rcu_arg_1/2() use one single
interface.
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/rcupdate.h | 18 ++
1 file
On Thu, Nov 19, 2020 at 09:40:29AM +0800, Huang, Ying wrote:
> Uladzislau Rezki writes:
>
> > On Wed, Nov 18, 2020 at 10:44:13AM +0800, huang ying wrote:
> >> On Tue, Nov 17, 2020 at 9:04 PM Uladzislau Rezki wrote:
> >> >
> >> > On Tue, Nov 1
On Wed, Nov 18, 2020 at 10:44:13AM +0800, huang ying wrote:
> On Tue, Nov 17, 2020 at 9:04 PM Uladzislau Rezki wrote:
> >
> > On Tue, Nov 17, 2020 at 10:37:34AM +0800, huang ying wrote:
> > > On Tue, Nov 17, 2020 at 6:00 AM Uladzislau Rezki (Sony)
> > > wrote
>
> Let's cc Uladzislau on vmalloc things?
>
> > How about this?
>
> Well, lol, that's a simple approach to avoiding the problem ;)
>
To me it looks like a specific workaround for a specific one user.
> > unmap_kernel_range had been atomic operation and zsmalloc has used
> > it in atomic
On Tue, Nov 17, 2020 at 10:37:34AM +0800, huang ying wrote:
> On Tue, Nov 17, 2020 at 6:00 AM Uladzislau Rezki (Sony)
> wrote:
> >
> > A current "lazy drain" model suffers from at least two issues.
> >
> > First one is related to the unsorted list of v
presents a
free space is faster because of (a). As a result the lock
contention is also reduced.
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/vmalloc.h | 8 ++--
mm/vmalloc.c| 90 +++--
2 files changed, 53 insertions(+
y the same, to perform
a cleanup.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d7075ad340aa..b08b06a8cc2a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2479,8 +2479,7 @@ s
On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote:
> Hi Andrew,
>
> On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote:
> > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote:
> >
> > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> > >
> > > While I was
> > > > * This is a per-CPU structure. The reason that it is not included in
> > > > @@ -3100,6 +3103,11 @@ struct kfree_rcu_cpu {
> > > > bool monitor_todo;
> > > > bool initialized;
> > > > int count;
> > > > +
> > > > + struct work_struct page_cache_work;
> > >
On Wed, Nov 04, 2020 at 06:12:00AM -0800, Paul E. McKenney wrote:
> On Wed, Nov 04, 2020 at 01:35:53PM +0100, Uladzislau Rezki wrote:
> > On Tue, Nov 03, 2020 at 11:18:22AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 03, 2020 at 05:33:50PM +0100, Uladzislau Rezki wrote:
>
On Tue, Nov 03, 2020 at 11:18:22AM -0800, Paul E. McKenney wrote:
> On Tue, Nov 03, 2020 at 05:33:50PM +0100, Uladzislau Rezki wrote:
> > On Tue, Nov 03, 2020 at 10:47:23AM -0500, Joel Fernandes wrote:
> > > On Thu, Oct 29, 2020 at 05:50:04PM +0100, Uladzislau
On Tue, Nov 03, 2020 at 12:54:22PM -0500, Joel Fernandes wrote:
> On Thu, Oct 29, 2020 at 05:50:04PM +0100, Uladzislau Rezki (Sony) wrote:
> > The current memmory-allocation interface presents to following
> > difficulties that this patch is designed to overcome
> [...]
>
Hello, Joel.
>
> On Thu, Oct 29, 2020 at 05:50:18PM +0100, Uladzislau Rezki (Sony) wrote:
> > Given that CONFIG_PREEMPT_COUNT is unconditionally enabled by the
> > earlier commits in this series, the preemptible() macro now properly
> > detects preempt-disable code regio
On Tue, Nov 03, 2020 at 10:47:23AM -0500, Joel Fernandes wrote:
> On Thu, Oct 29, 2020 at 05:50:04PM +0100, Uladzislau Rezki (Sony) wrote:
> > The current memmory-allocation interface presents to following
> > difficulties that this patch is designed to overcome:
>
On Thu, Oct 29, 2020 at 01:33:55PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 29, 2020 at 09:22:41PM +0100, Uladzislau Rezki wrote:
> > On Thu, Oct 29, 2020 at 09:13:42PM +0100, Uladzislau Rezki wrote:
> > > On Thu, Oct 29, 2020 at 12:47:24PM -0700, Paul E. McKenney wrote:
>
On Thu, Oct 29, 2020 at 05:50:09PM +0100, Uladzislau Rezki (Sony) wrote:
> From: Thomas Gleixner
>
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
>
> Signed-off-by: Thomas Gleixner
> Cc: Andre
On Thu, Oct 29, 2020 at 09:13:42PM +0100, Uladzislau Rezki wrote:
> On Thu, Oct 29, 2020 at 12:47:24PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 29, 2020 at 05:50:19PM +0100, Uladzislau Rezki (Sony) wrote:
> > > A CONFIG_PREEMPT_COUNT is unconditionally enabled, thu
On Thu, Oct 29, 2020 at 12:47:24PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 29, 2020 at 05:50:19PM +0100, Uladzislau Rezki (Sony) wrote:
> > A CONFIG_PREEMPT_COUNT is unconditionally enabled, thus a page
> > can be obtained directly from a kvfree_rcu() path. To distinguish
&g
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/pagemap.h | 4 +---
1 file
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Uladzislau Rezki (Sony)
---
arch/arm/include/asm
functionality of the kernel consistent
accross the various preemption models.
Enable CONFIG_PREEMPT_COUNT unconditionally. Follow up changes will remove
the #ifdeffery and remove the config option at the end.
Signed-off-by: Thomas Gleixner
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Uladzislau Rezki (Sony)
---
arch/xtensa
han
Cc: r...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Uladzislau Rezki (Sony)
---
tools/testing/selftests/rcutorture/configs/rcu/SRCU-t| 1 -
tools/testing/selftests/rcutorture/configs/rcu/SRCU-u| 1 -
tools/testing/selftests/rcutorture/configs/rcu/TINY01
-by: Uladzislau Rezki (Sony)
---
include/linux/lockdep.h | 6 ++
lib/Kconfig.debug | 1 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index f5594879175a..d05db575f60f 100644
--- a/include/linux/lockdep.h
+++ b/include
Segall
Cc: Mel Gorman
Cc: Daniel Bristot de Oliveira
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/preempt.h | 37 -
1 file changed, 4 insertions(+), 33 deletions(-)
diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index 7d9c1c0e149c
From: Thomas Gleixner
All conditionals and irritations are gone.
Signed-off-by: Thomas Gleixner
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/Kconfig.preempt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 3f4712ff073b
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Uladzislau Rezki (Sony)
---
drivers/gpu/drm/i915/Kconfig.debug | 1 -
drivers/gpu/drm/i915/i915_utils.h | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/uaccess.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
within the
memory allocator.
[ paulmck: Add add_ptr_to_bulk_krc_lock header comment per Michal Hocko. ]
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 48 ++-
1 file changed, 31 insertions(+), 17 deletions
Segall
Cc: Mel Gorman
Cc: Daniel Bristot de Oliveira
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/sched/core.c | 6 +-
lib/Kconfig.debug | 1 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d2003a7d5ab5..e172f2ddfa16 100644
y: Sebastian Andrzej Siewior
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 109 --
1 file changed, 66 insertions(+), 43 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 06895ef85d69..f2da2a1cc716 100644
--- a/kernel/rcu/
counter nor is there a reason to prevent the enablement of
CONFIG_DEBUG_ATOMIC_SLEEP on such architectures.
Remove the dependencies.
Signed-off-by: Thomas Gleixner
Signed-off-by: Uladzislau Rezki (Sony)
---
lib/Kconfig.debug | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib
. Switch to a delayed work, so the actual work is queued from
the timer interrupt with 1 jiffy delay. An immediate placing a task
on a current CPU can lead to rq->lock double lock. That is why a
delayed method is in place.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c |
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Acked-by: Will Deacon
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/bit_spinlock.h | 4 +---
1 file changed, 1
Hello.
> Hello,
>
> The kmem memcg selftest causes the following lockdep splat on 5.9+
>
> [ 67.534319] =
> [ 67.534410] [ BUG: Invalid wait context ]
> [ 67.534522] 5.9.1-22-default #125 Not tainted
> [ 67.534647] -
>
Working on
up PREEMPT_COUNT leftovers
> > > ARM: Cleanup PREEMPT_COUNT leftovers
> > > xtensa: Cleanup PREEMPT_COUNT leftovers
> > > drm/i915: Cleanup PREEMPT_COUNT leftovers
> > > rcutorture: Cleanup PREEMPT_COUNT leftovers
> > > preempt: Remove
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 16a6320addfc4692a79aa452eefd40460fff4959
Gitweb:
https://git.kernel.org/tip/16a6320addfc4692a79aa452eefd40460fff4959
Author:Uladzislau Rezki (Sony)
AuthorDate:Tue, 22 Sep 2020 21:06:22 +02:00
On Wed, Oct 07, 2020 at 12:02:34PM +0200, Michal Hocko wrote:
> On Wed 07-10-20 00:25:29, Uladzislau Rezki wrote:
> > On Mon, Oct 05, 2020 at 05:41:00PM +0200, Michal Hocko wrote:
> > > On Mon 05-10-20 17:08:01, Uladzislau Rezki wrote:
> > > > On Fri, Oct 02, 2020 at
On Mon, Oct 05, 2020 at 05:41:00PM +0200, Michal Hocko wrote:
> On Mon 05-10-20 17:08:01, Uladzislau Rezki wrote:
> > On Fri, Oct 02, 2020 at 11:05:07AM +0200, Michal Hocko wrote:
> > > On Fri 02-10-20 09:50:14, Mel Gorman wrote:
> > > > On Fri, Oct 02, 2020 at 09:11:
On Fri, Oct 02, 2020 at 11:05:07AM +0200, Michal Hocko wrote:
> On Fri 02-10-20 09:50:14, Mel Gorman wrote:
> > On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote:
> > > On Thu 01-10-20 21:26:26, Uladzislau Rezki wrote:
> > > > >
> > > > >
On Fri, Oct 02, 2020 at 09:06:24AM +0100, Mel Gorman wrote:
> On Thu, Oct 01, 2020 at 09:26:26PM +0200, Uladzislau Rezki wrote:
> > >
> > > No, I meant going back to idea of new gfp flag, but adjust the
> > > implementation in
> > > the allocator (dif
On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote:
> On Thu 01-10-20 21:26:26, Uladzislau Rezki wrote:
> > >
> > > No, I meant going back to idea of new gfp flag, but adjust the
> > > implementation in
> > > the allocator (different from
6cee168ccf8688bb8b872478
> > Author: Paul E. McKenney
> > Date: Wed Sep 30 16:16:39 2020 -0700
> >
> > kvfree_rcu(): Switch from kmalloc/kfree to __get_free_page/free_page.
> >
> > The advantages of using kmalloc() and kfree() are a possible small
On Wed, Sep 30, 2020 at 12:35:57PM +0200, Michal Hocko wrote:
> On Wed 30-09-20 00:07:42, Uladzislau Rezki wrote:
> [...]
> >
> > bool is_pcp_cache_empty(gfp_t gfp)
> > {
> > struct per_cpu_pages *pcp;
> > struct zoneref *ref;
> >
>
> No, I meant going back to idea of new gfp flag, but adjust the implementation
> in
> the allocator (different from what you posted in previous version) so that it
> only looks at the flag after it tries to allocate from pcplist and finds out
> it's empty. So, no inventing of new page
On Wed, Sep 30, 2020 at 06:46:00PM +0200, Michal Hocko wrote:
> On Wed 30-09-20 15:39:54, Uladzislau Rezki wrote:
> > On Wed, Sep 30, 2020 at 02:44:13PM +0200, Michal Hocko wrote:
> > > On Wed 30-09-20 14:35:35, Uladzislau Rezki wrote:
> > > > On Wed, Sep 30, 2020 at
On Wed, Sep 30, 2020 at 02:44:13PM +0200, Michal Hocko wrote:
> On Wed 30-09-20 14:35:35, Uladzislau Rezki wrote:
> > On Wed, Sep 30, 2020 at 11:27:32AM +0200, Michal Hocko wrote:
> > > On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote:
> > > > > > I look at
On Wed, Sep 30, 2020 at 11:27:32AM +0200, Michal Hocko wrote:
> On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote:
> > > > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability
> > > > to provide a memory service for contexts which are not allowed to
>
> > > What is the point of calling kmalloc for a PAGE_SIZE object? Wouldn't
> > > using the page allocator directly be better?
> >
> > Well, you guys gave me considerable heat about abusing internal allocator
> > interfaces, and kmalloc() and kfree() seem to be about as non-internal
> > as you
On Tue, Sep 29, 2020 at 12:15:34PM +0200, Vlastimil Babka wrote:
> On 9/18/20 9:48 PM, Uladzislau Rezki (Sony) wrote:
> > Some background and kfree_rcu()
> > ===
> > The pointers to be freed are stored in the per-cpu array to improve
> > perfo
mic reserves".
> + * The current implementation doesn't support NMI and few other strict
> + * non-preemptive contexts (e.g. raw_spin_lock). The same applies to
> %GFP_NOWAIT.
> *
> * %GFP_KERNEL is typical for kernel-internal allocations. The caller
> requires
> * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim.
> --
> 2.28.0
>
Reviewed-by: Uladzislau Rezki
> > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability
> > to provide a memory service for contexts which are not allowed to
> > sleep, RCU is part of them. Both flags used to provide such ability
> > before but not anymore.
> >
> > Do you agree with it?
>
> Yes this sucks.
On Fri, Sep 25, 2020 at 05:17:12PM +0100, Mel Gorman wrote:
> On Fri, Sep 25, 2020 at 05:31:29PM +0200, Uladzislau Rezki wrote:
> > > > > >
> > > > > > All good points!
> > > > > >
> > > > > > On the other hand, duplicati
> > > >
> > > > All good points!
> > > >
> > > > On the other hand, duplicating a portion of the allocator functionality
> > > > within RCU increases the amount of reserved memory, and needlessly most
> > > > of the time.
> > > >
> > >
> > > But it's very similar to what mempools are for.
> >
On Fri, Sep 25, 2020 at 10:15:52AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 24, 2020 at 05:21:12PM +0200, Uladzislau Rezki wrote:
> > On Thu, Sep 24, 2020 at 01:19:07PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 24, 2020 at 10:16:14AM +0200, Uladzislau Rezki wrote:
>
On Thu, Sep 24, 2020 at 01:19:07PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 24, 2020 at 10:16:14AM +0200, Uladzislau Rezki wrote:
> > The key point is "enough". We need pages to make a) fast progress b) support
> > single argument of kvfree_rcu(one_arg). Not
On Thu, Sep 24, 2020 at 01:16:32PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 24, 2020 at 10:16:14AM +0200, Uladzislau Rezki wrote:
> > Other option is if we had unconditionally enabled PREEMPT_COUNT config.
> > It would be easy to identify a context type and invoke a
> On Wed, Sep 23, 2020 at 08:41:05AM -0700, Paul E. McKenney wrote:
> > > Fundamentally, this is simply shifting the problem from RCU to the page
> > > allocator because of the locking arrangements and hazard of acquiring zone
> > > lock is a raw spinlock is held on RT. It does not even make the
> > > Other approaches under consideration include making CONFIG_PREEMPT_COUNT
> > > unconditional and thus allowing call_rcu() and kvfree_rcu() to determine
> > > whether direct calls to the allocator are safe (some guy named Linus
> > > doesn't like this one),
> >
> > I assume that the primary
101 - 200 of 601 matches
Mail list logo
