On Thu, Apr 15, 2021 at 06:10:26PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 15, 2021 at 07:19:55PM +0200, Uladzislau Rezki (Sony) wrote:
> > This is a v2 of a small series. See the changelog below:
> >
> > V1 -> V2:
> > - document the rcu_delay_page_cache_f
. There is no reason in
setting it force and back.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3ddc9dc97487..17c128d93825 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/r
To queue a new batch we have a kfree_rcu_monitor() function that
checks "monitor_todo" var. and invokes kfree_rcu_drain_unlock()
to start a new batch after a GP. Get rid of open-coded case by
switching it to the separate function.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/
s well
as "krcp->bkvhead[1]". So, we have to queue the "monitor work"
if _any_ corresponding channel is not empty.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c
nr_bkv_objs represents the counter of objects in the page-cache.
Accessing to it requires taking the lock. Switch to READ_ONCE()
WRITE_ONCE() macros to provide an atomic access to that counter.
A shrinker is one of the user of it.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c
Rezki (Sony)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Zqiang
---
.../admin-guide/kernel-parameters.txt | 5 ++
kernel/rcu/tree.c | 82 +--
2 files changed, 78 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide
s in
get_cached_bnode()/put_cached_bnode() it is protected
by the lock.
- Capitalize the word following by ":" in commit messages.
Uladzislau Rezki (Sony) (4):
[1] kvfree_rcu: Use [READ/WRITE]_ONCE() macros to access to nr_bkv_objs
[2] kvfree_rcu: Add a bulk-list check when a schedul
kthreads
earlier in boot. With this change, the above test passes.
Reported-by: Sebastian Andrzej Siewior
Reported-by: Uladzislau Rezki
Inspired-by: Uladzislau Rezki
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index bb8ff90
To queue a new batch we have a kfree_rcu_monitor() function that
checks KRC_MONITOR_TODO bit and invokes kfree_rcu_drain_unlock()
to start a new batch after a GP. Get rid of open-coded case by
switching it to the separate function.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c
note that checking/setting
this bit is protected by the krcp->lock spinlock.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index da3605067cc1..012030cbe55e 100
s well
as "krcp->bkvhead[1]". So, we have to queue the "monitor work"
if _any_ corresponding channel is not empty.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/tree.c
.
To access to the flags variable atomic bit operations are used.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 61 ---
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 1b0289fa1cdd
nr_bkv_objs represents the counter of objects in the page-cache.
Accessing to it requires taking the lock. Switch to READ_ONCE()
WRITE_ONCE() macros to provide an atomic access to that counter.
A shrinker is one of the user of it.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c
Rezki (Sony)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Zqiang
---
kernel/rcu/tree.c | 70 +--
1 file changed, 61 insertions(+), 9 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 2c9cf4df942c..8b74edcd11d4 100644
On Wed, Apr 14, 2021 at 09:13:22AM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-04-12 11:36:45 [-0700], Paul E. McKenney wrote:
> > > Color me confused. I did not follow the discussion around this
> > > completely, but wasn't it agreed on that this rcu torture muck can wait
> > > until the
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 148e3731d124079a036b3acf780f3d35c1b9c0aa
Gitweb:
https://git.kernel.org/tip/148e3731d124079a036b3acf780f3d35c1b9c0aa
Author:Uladzislau Rezki (Sony)
AuthorDate:Wed, 20 Jan 2021 17:21:46 +01:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 3e7ce7a187fc6aaa9fda1310a2b8da8770342ff7
Gitweb:
https://git.kernel.org/tip/3e7ce7a187fc6aaa9fda1310a2b8da8770342ff7
Author:Uladzislau Rezki (Sony)
AuthorDate:Fri, 29 Jan 2021 17:16:03 +01:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: ee6ddf58475cce8a3d3697614679cd8cb4a6f583
Gitweb:
https://git.kernel.org/tip/ee6ddf58475cce8a3d3697614679cd8cb4a6f583
Author:Uladzislau Rezki (Sony)
AuthorDate:Fri, 29 Jan 2021 21:05:05 +01:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 686fe1bf6bcce3ce9fc03c9d9035c643c320ca46
Gitweb:
https://git.kernel.org/tip/686fe1bf6bcce3ce9fc03c9d9035c643c320ca46
Author:Uladzislau Rezki (Sony)
AuthorDate:Wed, 17 Feb 2021 19:51:10 +01:00
Currently a maximum value is set to 1024 workers the user can
create during the test. It might be that for some big systems
it is not enough. Since it is a test thing we can give testers
more flexibility.
Increase that number till USHRT_MAX that corresponds to 65535.
Signed-off-by: Uladzislau
On Mon, Apr 05, 2021 at 07:39:20PM -0700, Andrew Morton wrote:
> On Sat, 3 Apr 2021 14:31:43 +0200 Uladzislau Rezki wrote:
>
> > >
> > > We may need to replaced that kcalloc() with kmvalloc() though...
> > >
> > Yep. If we limit to USHRT_MAX, the maximum
> On Fri, 2 Apr 2021 22:22:34 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > By using this parameter we can specify how many workers are
> > created to perform vmalloc tests. By default it is one CPU.
> > The maximum value is set to 1024.
> >
> &
> On Sat, Apr 3, 2021 at 1:53 AM Uladzislau Rezki (Sony)
> wrote:
> >
> > Signed-off-by: Uladzislau Rezki (Sony)
>
> How about merging it with patch [4/5] ?
>
I had in mind such concern. Yes we can do a squashing with [4/5].
If there are other comments i will rework
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 093c7e034ca2..1e643280cbcf 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1503,7 +1503,6 @@ static struct vmap_area *alloc_vmap_area(unsigned long
size
-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 60 +++-
1 file changed, 27 insertions(+), 33 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 8b564f91a610..093c7e034ca2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1430,6 +1430,29 @@ static void
er of CPUs.
Also update an output of help message based on a new interface.
CC: linux-kselft...@vger.kernel.org
CC: Shuah Khan
Signed-off-by: Uladzislau Rezki (Sony)
---
tools/testing/selftests/vm/test_vmalloc.sh | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --g
By using this parameter we can specify how many workers are
created to perform vmalloc tests. By default it is one CPU.
The maximum value is set to 1024.
As a result of this change a 'single_cpu_test' one becomes
obsolete, therefore it is no longer needed.
Signed-off-by: Uladzislau Rezki (Sony
Remove two test cases related to kvfree_rcu() and SLAB. Those are
considered as redundant now, because similar test functionality
has recently been introduced in the "rcuscale" RCU test-suite.
Signed-off-by: Uladzislau Rezki (Sony)
---
lib/test_vmal
> On Mon, Mar 29, 2021 at 08:14:53PM +0200, Uladzislau Rezki wrote:
> > On Mon, Mar 29, 2021 at 07:40:29PM +0200, Uladzislau Rezki wrote:
> > > On Mon, Mar 29, 2021 at 06:14:34PM +0100, Matthew Wilcox wrote:
> > > > On Mon, Mar 29, 2021 at 06:07:30PM +0100, Colin Kin
On Mon, Mar 29, 2021 at 08:14:53PM +0200, Uladzislau Rezki wrote:
> On Mon, Mar 29, 2021 at 07:40:29PM +0200, Uladzislau Rezki wrote:
> > On Mon, Mar 29, 2021 at 06:14:34PM +0100, Matthew Wilcox wrote:
> > > On Mon, Mar 29, 2021 at 06:07:30PM +0100, Colin King wrote:
> >
On Mon, Mar 29, 2021 at 07:40:29PM +0200, Uladzislau Rezki wrote:
> On Mon, Mar 29, 2021 at 06:14:34PM +0100, Matthew Wilcox wrote:
> > On Mon, Mar 29, 2021 at 06:07:30PM +0100, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Currently the memo
gt; >"page array size %lu allocation failed",
> > area->nr_pages * PAGE_SIZE, array_size);
> > + free_vm_area(area);
> > return NULL;
>
> this fix looks right to me.
>
That is from the linux-next. Same to me.
Reviewed-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
On Thu, Mar 25, 2021 at 02:26:24PM +, Mel Gorman wrote:
> On Thu, Mar 25, 2021 at 03:06:57PM +0100, Uladzislau Rezki wrote:
> > > On Thu, Mar 25, 2021 at 12:50:01PM +, Matthew Wilcox wrote:
> > > > On Thu, Mar 25, 2021 at 11:42:19AM +, Mel Gorman wrote:
> >
On Thu, Mar 25, 2021 at 02:09:27PM +, Matthew Wilcox wrote:
> On Thu, Mar 25, 2021 at 03:06:57PM +0100, Uladzislau Rezki wrote:
> > For the vmalloc we should be able to allocating on a specific NUMA node,
> > at least the current interface takes it into account. As far as i see
> On Thu, Mar 25, 2021 at 12:50:01PM +, Matthew Wilcox wrote:
> > On Thu, Mar 25, 2021 at 11:42:19AM +, Mel Gorman wrote:
> > > This series introduces a bulk order-0 page allocator with sunrpc and
> > > the network page pool being the first users. The implementation is not
> > > efficient
On Tue, Mar 23, 2021 at 09:39:24PM +0100, Uladzislau Rezki wrote:
> > On Tue, Mar 23, 2021 at 01:04:36PM +0100, Uladzislau Rezki wrote:
> > > On Mon, Mar 22, 2021 at 11:03:11PM +, Matthew Wilcox wrote:
> > > > I suspect the vast majority of the time is spent callin
>
> On 3/18/2021 10:29 PM, Uladzislau Rezki wrote:
> > On Thu, Mar 18, 2021 at 03:38:25PM +0530, vji...@codeaurora.org wrote:
> >> From: Vijayanand Jitta
> >>
> >> A potential use after free can occur in _vm_unmap_aliases
> >> where an alr
On Tue, Mar 23, 2021 at 02:07:22PM +, Matthew Wilcox wrote:
> On Tue, Mar 23, 2021 at 02:39:48PM +0100, Uladzislau Rezki wrote:
> > On Tue, Mar 23, 2021 at 12:39:13PM +, Matthew Wilcox wrote:
> > > On Tue, Mar 23, 2021 at 01:04:36PM +0100, Uladzislau Rezki wrote:
>
> On Tue, Mar 23, 2021 at 01:04:36PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 22, 2021 at 11:03:11PM +, Matthew Wilcox wrote:
> > > I suspect the vast majority of the time is spent calling
> > > alloc_pages_node()
> > > 1024 times. Have you looked at
On Tue, Mar 23, 2021 at 12:39:13PM +, Matthew Wilcox wrote:
> On Tue, Mar 23, 2021 at 01:04:36PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 22, 2021 at 11:03:11PM +, Matthew Wilcox wrote:
> > > I suspect the vast majority of the time is spent calling
>
On Mon, Mar 22, 2021 at 11:03:11PM +, Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 11:36:19PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 22, 2021 at 07:38:20PM +, Matthew Wilcox (Oracle) wrote:
> > > If we're trying to allocate 4MB of memory, the table wi
On Mon, Mar 22, 2021 at 07:38:20PM +, Matthew Wilcox (Oracle) wrote:
> If we're trying to allocate 4MB of memory, the table will be 8KiB in size
> (1024 pointers * 8 bytes per pointer), which can usually be satisfied
> by a kmalloc (which is significantly faster). Instead of changing this
>
On Tue, Mar 16, 2021 at 02:01:25PM -0700, Paul E. McKenney wrote:
> On Tue, Mar 16, 2021 at 09:42:07PM +0100, Uladzislau Rezki wrote:
> > > On Wed, Mar 10, 2021 at 09:07:57PM +0100, Uladzislau Rezki (Sony) wrote:
> > > > From: Zhang Qiang
> > > >
>
On Thu, Mar 18, 2021 at 03:38:25PM +0530, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> A potential use after free can occur in _vm_unmap_aliases
> where an already freed vmap_area could be accessed, Consider
> the following scenario:
>
> Process 1
> On Wed, Mar 10, 2021 at 09:07:57PM +0100, Uladzislau Rezki (Sony) wrote:
> > From: Zhang Qiang
> >
> > Add a drain_page_cache() function to drain a per-cpu page cache.
> > The reason behind of it is a system can run into a low memory
> > condition, in that cas
On Tue, Mar 16, 2021 at 10:01:46AM +0200, Topi Miettinen wrote:
> On 15.3.2021 19.47, Uladzislau Rezki wrote:
> > On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
> > > On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
> > > > On Mon, Ma
On Mon, Mar 15, 2021 at 06:23:37PM +0200, Topi Miettinen wrote:
> On 15.3.2021 17.35, Uladzislau Rezki wrote:
> > > On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > > > Also, using vmaloc test driver i can trigger a kernel BUG:
> > > >
> > > >
&
On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
> On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
> > > What's the problem with that? It seems to me that nothing relies
> On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > Also, using vmaloc test driver i can trigger a kernel BUG:
> >
> >
> > [ 24.627577] kernel BUG at mm/vmalloc.c:1272!
>
> It seems that most tests indeed fail. Perhaps the vmalloc subsystem isn't
> very
On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
> On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > > Memory mappings inside kernel allocated with vmalloc() are in
> > > predictable order and packed tightly toward the low addresses, except
> > > for per-
> Memory mappings inside kernel allocated with vmalloc() are in
> predictable order and packed tightly toward the low addresses, except
> for per-cpu areas which start from top of the vmalloc area. With
> new kernel boot parameter 'randomize_vmalloc=1', the entire area is
> used randomly to make
.
When a system hits such condition, a page cache is drained for
all CPUs in a system. Apart of that a page cache work is delayed
with 5 seconds interval until a memory pressure disappears.
Co-developed-by: Uladzislau Rezki (Sony)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Zqiang
X: 11312145160
patch: AVG: 10787596486.1 MIN: 10397559880 MAX: 11214901050
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.c | 91 +--
1 file changed, 56 insertions(+), 35 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.
.
When a system hits such condition, a page cache is drained for
all CPUs in a system. Apart of that a page cache work is delayed
with 5 seconds interval until a memory pressure disappears.
Co-developed-by: Uladzislau Rezki (Sony)
Signed-off-by: Uladzislau Rezki (Sony)
Signed-off-by: Zqiang
On Mon, Feb 22, 2021 at 10:16:08AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 22, 2021 at 06:16:05PM +0100, Uladzislau Rezki wrote:
> > On Mon, Feb 22, 2021 at 07:09:03AM -0800, Paul E. McKenney wrote:
> > > On Mon, Feb 22, 2021 at 01:54:31PM +0100, Uladzislau Rezki wrote:
>
On Mon, Feb 22, 2021 at 07:09:03AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 22, 2021 at 01:54:31PM +0100, Uladzislau Rezki wrote:
> > On Mon, Feb 22, 2021 at 11:21:04AM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2021-02-19 10:33:36 [-0800], Paul
On Mon, Feb 22, 2021 at 11:21:04AM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-02-19 10:33:36 [-0800], Paul E. McKenney wrote:
> > For definiteness, here is the first part of the change, posted earlier.
> > The commit log needs to be updated. I will post the change that keeps
> > the tick
On Fri, Feb 19, 2021 at 12:23:57PM +0100, Uladzislau Rezki wrote:
> On Fri, Feb 19, 2021 at 12:17:38PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2021-02-19 12:13:01 [+0100], Uladzislau Rezki wrote:
> > > I or Paul will ask for a test once it is settled down :) Looks like
On Fri, Feb 19, 2021 at 12:17:38PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-02-19 12:13:01 [+0100], Uladzislau Rezki wrote:
> > I or Paul will ask for a test once it is settled down :) Looks like
> > it is, so we should fix for v5.12.
>
> Okay. Since Paul asked for
On Fri, Feb 19, 2021 at 11:57:10AM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-02-19 11:49:58 [+0100], Uladzislau Rezki wrote:
> > If above fix works, we can initialize rcu_init_tasks_generic() from the
> > core_initcall() including selftst. It means that such initialization
> add these before (or even in place of) my Reported-by?
> >
> > Reported-by: Sebastian Andrzej Siewior
> > Reported-by: Uladzislau Rezki
> >
> > Other than that, looks good!
>
> Perfect. I'm kind of lost here, nevertheless ;) Does this mean that the
> RC
On Thu, Feb 18, 2021 at 02:03:07PM +0900, Masami Hiramatsu wrote:
> On Wed, 17 Feb 2021 10:17:38 -0800
> "Paul E. McKenney" wrote:
>
> > > > 1. Spawn ksoftirqd earlier.
> > > >
> > > > 2. Suppress attempts to awaken ksoftirqd before it exists,
> > > > forcing all ksoftirq
of this is that it allows testing of both
options with one test.
Suggested-by: Paul E. McKenney
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/rcuscale.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
index
On Tue, Feb 16, 2021 at 09:35:02AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 15, 2021 at 05:27:05PM +0100, Uladzislau Rezki wrote:
> > On Tue, Feb 09, 2021 at 05:00:52PM -0800, Paul E. McKenney wrote:
> > > On Tue, Feb 09, 2021 at 09:13:43PM +0100, Uladzislau Rezki wrote:
>
On Tue, Feb 09, 2021 at 05:00:52PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 09, 2021 at 09:13:43PM +0100, Uladzislau Rezki wrote:
> > On Thu, Feb 04, 2021 at 01:46:48PM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 29, 2021 at 09:05:04PM +0100, Uladzislau
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 5130b8fd06901c1b3a4bd0d0f5c5ea99b2b0a6f0
Gitweb:
https://git.kernel.org/tip/5130b8fd06901c1b3a4bd0d0f5c5ea99b2b0a6f0
Author:Uladzislau Rezki (Sony)
AuthorDate:Fri, 20 Nov 2020 12:49:16 +01:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 5ea5d1ed572cb5ac173674fe770252253d2d9e27
Gitweb:
https://git.kernel.org/tip/5ea5d1ed572cb5ac173674fe770252253d2d9e27
Author:Uladzislau Rezki (Sony)
AuthorDate:Fri, 20 Nov 2020 12:49:17 +01:00
On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:
> On 13.2.2021 13.55, Uladzislau Rezki wrote:
> > > Hello,
> > >
> > > Is there a chance of getting this reviewed and maybe even merged, please?
> > >
> > > -Topi
> > >
>
On Sat, Feb 13, 2021 at 08:45:54AM -0800, Paul E. McKenney wrote:
> On Sat, Feb 13, 2021 at 12:30:30PM +0100, Uladzislau Rezki wrote:
> > On Fri, Feb 12, 2021 at 04:43:28PM -0800, Paul E. McKenney wrote:
> > > On Fri, Feb 12, 2021 at 04:37:09PM -0800, Paul E. McKenney wrote:
>
> Hello,
>
> Is there a chance of getting this reviewed and maybe even merged, please?
>
> -Topi
>
I can review it and help with it. But before that i would like to
clarify if such "randomization" is something that you can not leave?
For example on 32bit system vmalloc space is limited, such
On Fri, Feb 12, 2021 at 04:43:28PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 12, 2021 at 04:37:09PM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 12, 2021 at 03:48:51PM -0800, Paul E. McKenney wrote:
> > > On Fri, Feb 12, 2021 at 10:12:07PM +0100, Uladzislau Rezki wrote:
>
On Fri, Feb 12, 2021 at 08:20:59PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-09 21:27:32 [+0100], Uladzislau Rezki (Sony) wrote:
> > Add self tests for checking of RCU-tasks API functionality.
> > It covers:
> > - wait API functions;
> > - invokin
> From: Zqiang
>
> Add free per-cpu existing krcp's page cache operation in shrink callback
> function, and also during shrink period, simple delay schedule fill page
> work, to avoid refill page while free krcp page cache.
>
> Signed-off-by: Zqiang
> Co-developed-by
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: bfba7ed084f8ab0269a5a1d2f51b07865456c334
Gitweb:
https://git.kernel.org/tip/bfba7ed084f8ab0269a5a1d2f51b07865456c334
Author:Uladzislau Rezki (Sony)
AuthorDate:Wed, 09 Dec 2020 21:27:32 +01:00
spin_lock(_area_lock);
> - list_for_each_entry(va, _area_list, list) {
> + va = __find_vmap_area((unsigned long)addr);
> + if (!va)
> + goto finished;
> + list_for_each_entry_from(va, _area_list, list) {
> if (!count)
> break;
>
> --
> 2.17.1
>
Much better :)
Reviewed-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
On Thu, Feb 04, 2021 at 01:46:48PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 29, 2021 at 09:05:04PM +0100, Uladzislau Rezki (Sony) wrote:
> > To stress and test a single argument of kfree_rcu() call, we
> > should to have a special coverage for it. We used to have it
> &
On Mon, Feb 08, 2021 at 03:53:03PM +, Serapheim Dimitropoulos wrote:
> vread() has been linearly searching vmap_area_list for looking up
> vmalloc areas to read from. These same areas are also tracked by
> a rb_tree (vmap_area_root) which offers logarithmic lookup.
>
> This patch modifies
Hello, Zqiang.
Thank you for your v4!
Some small nits see below:
> From: Zqiang
>
> Add free per-cpu existing krcp's page cache operation, when
> the system is under memory pressure.
>
> Signed-off-by: Zqiang
> Co-developed-by: Uladzislau Rezki (Sony)
> ---
>
On Thu, Feb 04, 2021 at 02:04:27PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 29, 2021 at 09:05:05PM +0100, Uladzislau Rezki (Sony) wrote:
> > Running an rcuscale stress-suite can lead to "Out of memory"
> > of a system. This can happen under high memory pressur
q(>lock);
>
> - call_rcu(>rcu, kvfree_rcu_local);
> + kvfree_rcu(old, rcu);
> return 0;
> }
>
> --
> 2.30.0.478.g8a0d178c01-goog
>
Reviewed-by: Uladzislau Rezki
--
Vlad Rezki
Hello, Paul.
> To stress and test a single argument of kfree_rcu() call, we
> should to have a special coverage for it. We used to have it
> in the test-suite related to vmalloc stressing. The reason is
> the rcuscale is a correct place for RCU related things.
>
> Signed-off-by
> 发件人: Uladzislau Rezki
> 发送时间: 2021年2月2日 3:57
> 收件人: Zhang, Qiang
> 抄送: ure...@gmail.com; paul...@kernel.org; j...@joelfernandes.org;
> r...@vger.kernel.org; linux-kernel@vger.kernel.org
> 主题: Re: [PATCH v3] kvfree_rcu: Release page cache under memory pressure
>
> [
Hello, Zqiang.
> From: Zqiang
>
> Add free per-cpu existing krcp's page cache operation, when
> the system is under memory pressure.
>
> Signed-off-by: Zqiang
> ---
> kernel/rcu/tree.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/kernel/rcu/tree.c
On Mon, Feb 01, 2021 at 12:47:55PM +0100, Michal Hocko wrote:
> On Fri 29-01-21 17:35:31, Uladzislau Rezki wrote:
> > On Fri, Jan 29, 2021 at 09:56:29AM +0100, Michal Hocko wrote:
> > > On Thu 28-01-21 19:02:37, Uladzislau Rezki wrote:
> &g
On Sat, Jan 30, 2021 at 06:47:31AM +, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月29日 22:19
> 收件人: Zhang, Qiang
> 抄送: ure...@gmail.com; paul...@kernel.org; j...@joelfernandes.org;
> r...@vger.
reserves.
With this change an rcuscale and the parameters which are in question
never runs into "Kernel panic".
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 1e86212
To stress and test a single argument of kfree_rcu() call, we
should to have a special coverage for it. We used to have it
in the test-suite related to vmalloc stressing. The reason is
the rcuscale is a correct place for RCU related things.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu
On Fri, Jan 29, 2021 at 09:56:29AM +0100, Michal Hocko wrote:
> On Thu 28-01-21 19:02:37, Uladzislau Rezki wrote:
> [...]
> > >From 0bdb8ca1ae62088790e0a452c4acec3821e06989 Mon Sep 17 00:00:00 2001
> > From: "Uladzislau Rezki (Sony)"
> > Date: Wed, 20 Jan 20
On Thu, Jan 28, 2021 at 04:30:17PM +0100, Uladzislau Rezki wrote:
> On Thu, Jan 28, 2021 at 04:17:01PM +0100, Michal Hocko wrote:
> > On Thu 28-01-21 16:11:52, Uladzislau Rezki wrote:
> > > On Mon, Jan 25, 2021 at 05:25:59PM +0100, Uladzislau Rezki wrote:
> > > > On M
On Wed, Jan 20, 2021 at 05:21:47PM +0100, Uladzislau Rezki (Sony) wrote:
> From: "Paul E. McKenney"
>
> This commit applies the __GFP_NOMEMALLOC gfp flag to memory allocations
> carried out by the single-argument variant of kvfree_rcu(), thus avoiding
> this can-sle
Hello, Zqiang.
See below some nits:
>
> Add free per-cpu existing krcp's page cache operation, when
> the system is under memory pressure.
>
> Signed-off-by: Zqiang
> ---
> kernel/rcu/tree.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git
On Thu, Jan 28, 2021 at 04:17:01PM +0100, Michal Hocko wrote:
> On Thu 28-01-21 16:11:52, Uladzislau Rezki wrote:
> > On Mon, Jan 25, 2021 at 05:25:59PM +0100, Uladzislau Rezki wrote:
> > > On Mon, Jan 25, 2021 at 04:39:43PM +0100, Michal Hocko wrote:
> > > > On Mon
On Mon, Jan 25, 2021 at 05:25:59PM +0100, Uladzislau Rezki wrote:
> On Mon, Jan 25, 2021 at 04:39:43PM +0100, Michal Hocko wrote:
> > On Mon 25-01-21 15:31:50, Uladzislau Rezki wrote:
> > > > On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote:
> > > > > F
On Wed, Jan 27, 2021 at 09:00:27AM +, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月26日 22:07
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki; Paul E. McKenney; r...@vger.kernel.org;
> linux-kernel@vger.ker
>
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月22日 22:31
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki; Paul E. McKenney; r...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> 主题: Re: 回复: [PATCH] rcu: Release per-cpu krcp page cache when
On Tue, Jan 26, 2021 at 09:33:40AM +, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月25日 21:49
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki; LKML; RCU; Paul E . McKenney; Michael Ellerman; Andrew
> Morton;
>
>
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月25日 5:57
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki (Sony); LKML; RCU; Paul E . McKenney; Michael Ellerman;
> Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj Upadhyay; Joel
> F
On Mon, Jan 25, 2021 at 04:39:43PM +0100, Michal Hocko wrote:
> On Mon 25-01-21 15:31:50, Uladzislau Rezki wrote:
> > > On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote:
> > > > For a single argument we can directly request a page from a caller
> > > &
> On Wed 20-01-21 17:21:46, 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 spots. Instead
> > of hitting a slow path we can request an extra page by dem
Hello, Zhang.
> >
> >发件人: Uladzislau Rezki (Sony)
> >发送时间: 2021年1月21日 0:21
> >收件人: LKML; RCU; Paul E . McKenney; Michael Ellerman
> >抄送: Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj >Upadhyay;
> >Joel
1 - 100 of 601 matches
Mail list logo
