.
>
> Regarding the reduction of the number of OPP changes, will the
> util_est feature provide the same amount of reduction by directly
> providing the estimated max utilization ?
>
> Just to say that IMHO skipping or not OPP change at dequeue is a
> policy decision and not a generic one
>
Indeed. Otherwise we may end up in a situation of handling corner
cases in a scheduler when it comes to OPP updates. I also agree that
it is up to policy to do update or not.
--
Uladzislau Rezki
On Tue, Nov 13, 2018 at 02:10:46PM -0800, Andrew Morton wrote:
> On Tue, 13 Nov 2018 16:16:29 +0100 "Uladzislau Rezki (Sony)"
> wrote:
>
> > This adds a new kernel module for analysis of vmalloc allocator. It is
> > only enabled as a module. There are two main re
On Fri, Jan 04, 2019 at 11:34:30AM -0700, shuah wrote:
> On 1/3/19 7:21 AM, Uladzislau Rezki (Sony) wrote:
> > Add the test script for the kernel test driver to analyse vmalloc
> > allocator for benchmarking and stressing purposes. It is just a kernel
> > module loader. You
On Mon, Dec 31, 2018 at 10:50:22AM -0800, Matthew Wilcox wrote:
> On Mon, Dec 31, 2018 at 02:26:38PM +0100, Uladzislau Rezki (Sony) wrote:
> > +#ifdef CONFIG_TEST_VMALLOC_MODULE
> > +EXPORT_SYMBOL(__vmalloc_node_range);
> > +#endif
>
> Definitely needs to be _GPL.
On Mon, Dec 31, 2018 at 10:47:55AM -0700, shuah wrote:
> On 12/31/18 6:26 AM, Uladzislau Rezki (Sony) wrote:
> > Add the test script for the kernel test driver to analyse vmalloc
> > allocator for benchmarking and stressing purposes. It is just a kernel
> > module loader. You
On Tue, Oct 23, 2018 at 08:26:40AM -0700, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote:
> > Hi Michal,
> >
> > On 10/23/2018 01:23 AM, Michal Hocko wrote:
> > > Hi Shuah,
> > >
> > > On Mon 22-10-18 18:52:5
Hi.
On Wed, Oct 24, 2018 at 08:22:52AM +0200, Michal Hocko wrote:
> On Tue 23-10-18 12:30:44, Joel Fernandes wrote:
> > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote:
> > > On 10/23/2018 11:05 AM, Michal Hocko wrote:
> > > > On Tue 23-10-18 08:26:40, Matthew Wilcox wrote:
> > > >> On
On Wed, Oct 24, 2018 at 04:01:06PM -0700, Andrew Morton wrote:
> On Fri, 19 Oct 2018 19:35:36 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > improving vmalloc allocator
>
> It's about time ;)
>
> Are you aware of https://lwn.net/Articles/285341/
On Thu, Oct 25, 2018 at 10:43:27AM +0200, Michal Hocko wrote:
> On Wed 24-10-18 19:34:18, Uladzislau Rezki wrote:
> > Hi.
> >
> > On Wed, Oct 24, 2018 at 08:22:52AM +0200, Michal Hocko wrote:
> > > On Tue 23-10-18 12:30:44, Joel Fernandes wrote:
> > > >
On Fri, Oct 19, 2018 at 10:44:39PM +, Roman Gushchin wrote:
> On Fri, Oct 19, 2018 at 07:35:36PM +0200, Uladzislau Rezki (Sony) wrote:
> > Objective
> > -
> > Initiative of improving vmalloc allocator comes from getting many issues
> > related to allocation
On Fri, Oct 19, 2018 at 05:11:45PM -0700, Joel Fernandes wrote:
> On Fri, Oct 19, 2018 at 07:35:36PM +0200, Uladzislau Rezki (Sony) wrote:
> > Objective
> > -
> > Initiative of improving vmalloc allocator comes from getting many issues
> > related to allocation
On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote:
> Hi,
> I haven't read through the implementation yet but I have say that I
> really love this cover letter. It is clear on intetion, it covers design
> from high level enough to start discussion and provides a very nice
> testing covera
d even after that i am not able to get any "WARNING in kvfree_rcu_bulk".
urezki@pc638:~$ uname -a
Linux pc638 6.11.0-rc2+ #3827 SMP PREEMPT_DYNAMIC Wed Sep 4 19:37:22 CEST 2024
x86_64 GNU/Linux
urezki@pc638:~$
is it easy to reproduce? Am i missing something in my setup?
--
Uladzislau Rezki
On Tue, Sep 10, 2024 at 08:42:54AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 20, 2024 at 05:59:35PM +0200, Uladzislau Rezki (Sony) wrote:
> > Add a kvfree_rcu_barrier() function. It waits until all
> > in-flight pointers are freed over RCU machinery. It does
> > not wait
disabled
is about list corruption BUG. So they are different and looks like
something is corrupted. So i would not trust that your report is about
kvfree_rcu_bulk() warning is related to a real issue with kvfree_rcu()
call.
A also run the reproducer on the 6.11.0-rc7 kernel. It still runs
without any panics yet.
Could you please test the latest kernel? For example 6.11.0-rc7?
--
Uladzislau Rezki
On Wed, Sep 11, 2024 at 03:39:19AM -0700, Paul E. McKenney wrote:
> On Wed, Sep 11, 2024 at 11:43:54AM +0200, Uladzislau Rezki wrote:
> > On Tue, Sep 10, 2024 at 08:42:54AM -0700, Paul E. McKenney wrote:
> > > On Tue, Aug 20, 2024 at 05:59:35PM +0200, Uladzislau Rezki (Sony) wr
On Thu, Sep 12, 2024 at 11:07:24AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 12, 2024 at 06:16:56PM +0200, Uladzislau Rezki wrote:
> > On Wed, Sep 11, 2024 at 03:39:19AM -0700, Paul E. McKenney wrote:
> > > On Wed, Sep 11, 2024 at 11:43:54AM +0200, Uladzislau Rezki wrote:
>
kernel image,
> Dockerfile that can be used to compile the kernel.
> I hope this repo will be helpful for analyzing the bug.
>
Could you please help to bisect this bug then?
Thanks!
--
Uladzislau Rezki
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 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 Rezki (Sony)
On Tue, Feb 27, 2018 at 05:06:43AM -0800, Matthew Wilcox wrote:
> On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote:
> > During finding a suitable hole in the vmap_area_list
> > there is an explicit rescheduling check for latency reduction.
> > We d
Hello, Roman.
> >
> > So, does it mean that this function always returns two following elements?
> > Can't it return a single element using the return statement instead?
> > The second one can be calculated as ->next?
> >
> Yes, they follow each other and if you return "prev" for example you can
Hello, Roman.
>
> Hello, Uladzislau!
>
> Yeah, the version above looks much simpler!
> Looking forward for the next version of the patchset.
>
> Thanks!
Will upload it soon.
Thanks!
--
Vlad Rezki
On Mon, Apr 01, 2019 at 03:59:39PM -0700, Andrew Morton wrote:
> On Mon, 1 Apr 2019 13:03:47 +0200 Uladzislau Rezki wrote:
>
> > Hello, Andrew.
> >
> > >
> > > It's a lot of new code. I t looks decent and I'll toss it in there for
> > > f
Hello, Roman.
>
> Reviewed-by: Roman Gushchin
>
> Thanks!
I appreciate your effort in reviewing to make it better.
Thank you!
--
Uladzislau Rezki
> 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-develop
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
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:
>
> 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 ra
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:
>
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 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 execu
> 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
&g
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
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 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
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 a/kernel/rcu/tree.
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-sleep co
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 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 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.
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
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 b/ke
> 发件人: 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
>
> [Ple
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
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 vrea
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
> &
;
> spin_lock(&vmap_area_lock);
> - list_for_each_entry(va, &vmap_area_list, list) {
> + va = __find_vmap_area((unsigned long)addr);
> + if (!va)
> + goto finished;
> + list_for_each_entry_from(va, &vmap_area_list, list) {
> if (!count)
> break;
>
> --
> 2.17.1
>
Much better :)
Reviewed-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
>
> I actually found it in RT 4.4 kernel, I thought this was also on newer RT
> kernels as well (is that not true anymore?). But yes it was exactly what
> Peter said.
>
I see it also in 5.6.4 linut-rt-devel:
#ifdef CONFIG_PREEMPT_RT
...
# define get_local_ptr(var) ({ \
migrate_disable(); \
thi
On Mon, Aug 10, 2020 at 09:25:25PM +0200, Michal Hocko wrote:
> On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote:
> > > On Sun 09-08-20 22:43:53, Uladzislau Rezki (Sony) wrote:
> > > [...]
> > > > Limitations and concerns (Main part)
> > > > ===
On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote:
> On Mon 10-08-20 21:25:26, Michal Hocko wrote:
> > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote:
> [...]
> > > The problem that i see is we can not use the page allocator from atomic
> > &
On Tue, Aug 11, 2020 at 11:37:13AM +0200, Uladzislau Rezki wrote:
> On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote:
> > On Mon 10-08-20 21:25:26, Michal Hocko wrote:
> > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote:
> > [...]
> > > > The prob
On Tue, Aug 11, 2020 at 12:28:18PM +0200, Michal Hocko wrote:
> On Tue 11-08-20 11:42:51, Uladzislau Rezki wrote:
> > On Tue, Aug 11, 2020 at 11:37:13AM +0200, Uladzislau Rezki wrote:
> > > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote:
> [...]
> > >
On Tue, Aug 11, 2020 at 12:21:24PM +0200, Michal Hocko wrote:
> On Tue 11-08-20 11:18:07, Uladzislau Rezki wrote:
> > On Mon, Aug 10, 2020 at 09:25:25PM +0200, Michal Hocko wrote:
> > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote:
> > > > > On Sun 09-08-20
On Tue, Aug 11, 2020 at 12:26:49PM +0200, Michal Hocko wrote:
> On Tue 11-08-20 11:37:13, Uladzislau Rezki wrote:
> > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote:
> > > On Mon 10-08-20 21:25:26, Michal Hocko wrote:
> > > > On Mon 10-08-20 18
On Wed, Aug 12, 2020 at 01:38:35PM +0200, Thomas Gleixner wrote:
> Thomas Gleixner writes:
> > Thomas Gleixner writes:
> >> Michal Hocko writes:
> >>> zone->lock should be held for a very limited amount of time.
> >>
> >> Emphasis on should. free_pcppages_bulk() can hold it for quite some time
>
> On Sun 09-08-20 22:43:53, Uladzislau Rezki (Sony) wrote:
> [...]
> > Limitations and concerns (Main part)
> >
> > The current memmory-allocation interface presents to following
> > difficulties that this patch is designed to
Hello, Michal.
You mentioned somewhere in the thread to show figures regarding hitting
a fast path and "fallback one". We follow fallback when a page allocation fails.
Please see below the plot. I hope it is easy to understand:
wget
ftp://vps418301.ovh.net/incoming/100_kfree_rcu_fast_hit_vs
> On Tue, Aug 18, 2020 at 03:00:35PM -0400, Joel Fernandes wrote:
> > On Tue, Aug 18, 2020 at 1:18 PM Paul E. McKenney wrote:
> > >
> > > On Mon, Aug 17, 2020 at 06:03:54PM -0400, Joel Fernandes wrote:
> > > > On Fri, Aug 14, 2020 at 2
On Tue, Aug 18, 2020 at 08:04:20PM -0400, Joel Fernandes wrote:
> On Tue, Aug 18, 2020 at 6:02 PM Paul E. McKenney wrote:
>
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index b8ccd7b5af82..6decb9ad2421 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -
_
> > > 发件人: linux-kernel-ow...@vger.kernel.org
> > > 代表 Joel Fernandes
> > >
> > > 发送时间: 2020年8月19日 8:04
> > > 收件人: Paul E. McKenney
> > > 抄送: Uladzislau Rezki; Zhang, Qiang; Josh Triplett; Steven Rostedt;
> > > Mathieu Desnoyers; La
>> 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
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.
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
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 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 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 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.
> > > >
> >
area->nr_pages = count;
> + }
> return area->addr;
> }
> EXPORT_SYMBOL(vmap);
> --
> 2.19.1
>
Reviewed-by: Uladzislau Rezki (Sony)
--
Vlad Rezki
ree_rcu() - kvfree an object after a grace period.
> --
> 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
>
> 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 already free
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 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 a
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 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 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 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 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
> op
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 tab
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 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 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 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 re
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 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 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 failure: "
> >"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 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 memory poin
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 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
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 bb
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_fill_
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 thr
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 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
> 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 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 go
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 E. McKenney
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 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
1 - 100 of 669 matches
Mail list logo
