and get rid of duplication.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b8101030f79e..e03444598ae1 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -385,17
where it can be used: vmalloc and lib/rbtree_test.c.
Appreciate for any comments.
Uladzislau Rezki (Sony) (2):
augmented rbtree: use max3() in the *_compute_max() function
mm/vmalloc: use generated callback to populate subtree_max_size
include/linux/rbtree_augmented.h | 40
Hello, Michel.
>
> Hmmm, I had not thought about that. Agree that this can be useful -
> there is already similar test code in rbtree_test.c and also
> vma_compute_subtree_gap() in mmap.c, ...
>
> With patch 3/3 of this series, the RBCOMPUTE function (typically
> generated through the
kes sense to me. I also can reproduce
that issue, so i agree with your patch. Basically we can skip free VA
block(that can fit) examining previous one(my fault), instead of moving
base downwards and recheck an area that did not fit.
Reviewed-by: Uladzislau Rezki (Sony)
Appreciate you for fixing it!
--
Vlad Rezki
Hello, Sathyanarayanan.
>
> I agree with Dave. I don't think this issue is related to NUMA. The problem
> here is about the logic we use to find appropriate vm_area that satisfies
> the offset and size requirements of pcpu memory allocator.
>
> In my test case, I can reproduce this issue if we
On Mon, Jul 29, 2019 at 04:21:39PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Recent changes to the vmalloc code by Commit 68ad4a330433
> ("mm/vmalloc.c: keep track of free blocks for vmap allocation") can
> cause spurious percpu allocation
>
> ---
> a/lib/rbtree_test.c~augmented-rbtree-add-new-rb_declare_callbacks_max-macro-fix-2
> +++ a/lib/rbtree_test.c
> @@ -220,10 +220,6 @@ static void check_augmented(int nr_nodes
> struct rb_node *rb;
>
> check(nr_nodes);
> - for (rb = rb_first(_root); rb; rb = rb_next(rb))
>
> Note for Uladzislau Rezki, I noticed that the new augmented rbtree
> code defines its own augment_tree_propagate_from function to update
> the augmented subtree information after a node is modified; it would
> probably be feasible to rely o
in "busy" tree
> C) "purge_list" is only used when vmap_area is in
>vmap_purge_list
>
> 2) Eliminate "flags".
> Since only one flag VM_VM_AREA is being used, and the same
> thing can be done by judging whether "vm&quo
in "busy" tree
> C) "purge_list" is only used when vmap_area is in
>vmap_purge_list
>
> 2) Eliminate "flags".
> Since only one flag VM_VM_AREA is being used, and the same
> thing can be done by judging whether "vm&quo
and keep
WARN_ON(RB_EMPTY_NODE(>rb_node) in place as it used to be.
Appreciate for any comments and review.
Uladzislau Rezki (Sony) (1):
mm/vmalloc: do not keep unpurged areas in the busy tree
mm/vmalloc.c | 52
1 file changed, 44 insertions(+), 8 deletions(-)
--
2.11.0
ps: 100 avg: 12593929 usec
2) Since the busy tree now contains allocated areas only and does
not interfere with lazily free nodes, introduce the new function
show_purge_info() that dumps "unpurged" areas that is propagated
through "/proc/vmallocinfo".
3) Eliminate VM_LAZY
On Fri, Jul 12, 2019 at 11:09:00PM +0800, Pengfei Li wrote:
> On Fri, Jul 12, 2019 at 9:49 PM Matthew Wilcox wrote:
> >
> > On Fri, Jul 12, 2019 at 08:02:13PM +0800, Pengfei Li wrote:
> >
> > I don't think you need struct union struct union. Because llist_node
> > is just a pointer, you can get
Hello, Li.
>
> v1 -> v2:
> * patch 3: Rename __find_vmap_area to __search_va_in_busy_tree
>instead of __search_va_from_busy_tree.
> * patch 5: Add motivation and necessary test data to the commit
>message.
> * patch 5: Let va->flags use only some low bits of va_start
>
ps: 100 avg: 12593929 usec
2) Since the busy tree now contains allocated areas only and does
not interfere with lazily free nodes, introduce the new function
show_purge_info() that dumps "unpurged" areas that is propagated
through "/proc/vmallocinfo".
3) Eliminate VM_LAZY
On Mon, Jul 01, 2019 at 11:20:37AM +0200, Michal Hocko wrote:
> On Sun 30-06-19 15:56:45, Pengfei Li wrote:
> > Hi,
> >
> > This series of patches is to reduce the size of struct vmap_area.
> >
> > Since the members of struct vmap_area are not being used at the same time,
> > it is possible to
unsigned long nva_start_addr, unsigned long size,
> enum fit_type type)
> {
> - struct vmap_area *lva;
> + struct vmap_area *lva = NULL;
>
> if (type == FL_FIT_TYPE) {
> /*
> --
> 2.18.0
>
--
Uladzislau Rezki
On Tue, Jun 18, 2019 at 01:59:20PM -0700, Andrew Morton wrote:
> On Tue, 18 Jun 2019 16:06:22 +0200 Uladzislau Rezki wrote:
>
> > On Tue, Jun 18, 2019 at 09:40:28AM -0400, Joel Fernandes wrote:
> > > On Tue, Jun 18, 2019 at 5:27 AM Arnd Bergmann wrote:
> > &g
hes, therefore set
> > +* it NULL here to avoid a warning.
> > + */
> > + struct vmap_area *lva = NULL;
>
> Fair enough, but is this 5-line comment really needed here?
>
How it is rewritten now, probably not. I would just set it NULL and
leave the comment, but that is IMHO. Anyway
Reviewed-by: Uladzislau Rezki (Sony)
Thanks!
--
Vlad Rezki
Hello, Arnd.
>
> Nevermind, the warning came back after all. It's now down to
> one out of 2000 randconfig builds I tested, but that's not good
> enough. I'll send a patch the way you suggested.
>
Makes sense to me :)
Thank you.
--
Vlad Rezki
>
> I managed to un-confuse gcc-8 by turning the if/else if/else into
> a switch statement. If you all think this is an acceptable solution,
> I'll submit that after some more testing to ensure it addresses
> all configurations:
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index
On Mon, Jun 17, 2019 at 02:14:11PM +0200, Arnd Bergmann wrote:
> gcc points out some obviously broken code in linux-next
>
> mm/vmalloc.c: In function 'pcpu_get_vm_areas':
> mm/vmalloc.c:991:4: error: 'lva' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>
victable:2 dirty:0 writeback:0 unstable:0
slab_reclaimable:2380 slab_unreclaimable:7520
mapped:15069 shmem:14813 pagetables:10833 bounce:0
free:1922 free_pcp:229 free_cma:0
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmal
Trigger a warning if an object that is about to be freed is detached.
We used to have a BUG_ON(), but even though it is considered as faulty
behaviour that is not a good reason to break a system.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 25 ++---
1 file
points to an object that must be linked.
Signed-off-by: Uladzislau Rezki (Sony)
Acked-by: Hillf Danton
Reviewed-by: Roman Gushchin
---
mm/vmalloc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index fcda966589a6..a4bdf5fc3512 10064
Remove unused argument from the __alloc_vmap_area() function.
Signed-off-by: Uladzislau Rezki (Sony)
Reviewed-by: Andrew Morton
Reviewed-by: Roman Gushchin
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index bed6a065f73a
essage of the [4].
v2->v3:
- remove the odd comment from the [3];
v1->v2:
- update the commit message. [2] patch;
- fix typos in comments. [2] patch;
- do the "preload" for NUMA awareness. [2] patch;
Uladzislau Rezki (Sony) (4):
mm/vmalloc.c: remove "node"
On Mon, Jun 03, 2019 at 07:53:12PM +0200, Uladzislau Rezki wrote:
> Hello, Roman!
>
> On Wed, May 29, 2019 at 04:34:40PM +, Roman Gushchin wrote:
> > On Wed, May 29, 2019 at 04:27:15PM +0200, Uladzislau Rezki wrote:
> > > Hello, Roman!
> > >
> > >
Hello, Roman!
On Wed, May 29, 2019 at 04:34:40PM +, Roman Gushchin wrote:
> On Wed, May 29, 2019 at 04:27:15PM +0200, Uladzislau Rezki wrote:
> > Hello, Roman!
> >
> > > On Mon, May 27, 2019 at 11:38:40AM +0200, Uladzislau Rezki (Sony) wrote:
> > > > Refa
Hello, Roman!
On Wed, May 29, 2019 at 04:26:43PM +, Roman Gushchin wrote:
> On Wed, May 29, 2019 at 03:58:17PM +0200, Uladzislau Rezki wrote:
> > Hello, Roman!
> >
> > > > Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
> > > > functio
/serial0
> https://krzk.eu/#/builders/22/builds/1118/steps/35/logs/serial0
>
> Bisect pointed to:
> 728e0fbf263e3ed359c10cb13623390564102881 is the first bad commit
> commit 728e0fbf263e3ed359c10cb13623390564102881
> Author: Uladzislau Rezki (Sony)
> Date: Sat Jun 1 12:20:19 2019 +1000
> mm/vmalloc.c: g
Hello, Roman!
> On Mon, May 27, 2019 at 11:38:40AM +0200, Uladzislau Rezki (Sony) wrote:
> > Refactor the NE_FIT_TYPE split case when it comes to an
> > allocation of one extra object. We need it in order to
> > build a remaining space.
> >
> > Introduce ne
Hello, Roman!
> > Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
> > function, it means if an empty node gets freed it is a BUG
> > thus is considered as faulty behaviour.
>
> It's not exactly clear from the description, why it's better.
>
It is rather about if "unlink" happens on
On Tue, May 28, 2019 at 01:18:09PM +0100, Naresh Kamboju wrote:
> Add test_vmalloc.sh to TEST_FILES to make sure it gets installed for
> run_vmtests.
>
> Fixed below error:
> ./run_vmtests: line 217: ./test_vmalloc.sh: No such file or directory
>
> Tested with: make TARGETS=vm install
points to an object that must
be linked.
Signed-off-by: Uladzislau Rezki (Sony)
Acked-by: Hillf Danton
---
mm/vmalloc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b553047aa05b..371aba9a4bf1 100644
--- a/mm/vmalloc.c
+++ b/mm
Trigger a warning if an object that is about to be freed is
detached. We used to have a BUG_ON(), but even though it is
considered as faulty behaviour that is not a good reason to
break a system.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 8 +---
1 file changed, 1 insertion
- fix typos in comments. [2] patch;
- do the "preload" for NUMA awareness. [2] patch;
Uladzislau Rezki (Sony) (4):
mm/vmap: remove "node" argument
mm/vmap: preload a CPU with one object for split purpose
mm/vmap: get rid of one single unlink_va() when merge
mm/vmap:
Remove unused argument from the __alloc_vmap_area() function.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..ea1b65fac599 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
is NE_FIT_TYPE.
The preload is done per CPU in non-atomic context thus with
GFP_KERNEL allocation masks. More permissive parameters can
be beneficial for systems which are suffer from high memory
pressure or low memory condition.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 79
> > Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
> > function, it means if an empty node gets freed it is a BUG
> > thus is considered as faulty behaviour.
>
> Can we switch it to a WARN_ON(). We are trying to remove all BUG_ON()s.
> If a user wants to crash on warning, there's a
is NE_FIT_TYPE.
The preload is done per CPU in non-atomic context thus with
GFP_KERNEL allocation masks. More permissive parameters can
be beneficial for systems which are suffer from high memory
pressure or low memory condition.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 79
Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
function, it means if an empty node gets freed it is a BUG
thus is considered as faulty behaviour.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions
odes. Therefore we can say
that removing detached object is a bug in all cases.
v2->v3:
- remove the odd comment from the [3];
v1->v2:
- update the commit message. [2] patch;
- fix typos in comments. [2] patch;
- do the "preload" for NUMA awareness. [2] patc
Remove unused argument from the __alloc_vmap_area() function.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..ea1b65fac599 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
points to an object that must
be linked.
Signed-off-by: Uladzislau Rezki (Sony)
Acked-by: Hillf Danton
---
mm/vmalloc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b553047aa05b..371aba9a4bf1 100644
--- a/mm/vmalloc.c
+++ b/mm
On Mon, May 27, 2019 at 11:07:12AM +0800, Hillf Danton wrote:
>
> On Mon, 27 May 2019 05:22:28 +0800 Uladzislau Rezki (Sony) wrote:
> > It does not make sense to try to "unlink" the node that is
> > definitely not linked with a list nor tree. On the first
&
is NE_FIT_TYPE.
The preload is done per CPU in non-atomic context thus with
GFP_KERNEL allocation masks. More permissive parameters can
be beneficial for systems which are suffer from high memory
pressure or low memory condition.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 79
points to an object that must
be linked.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b553047aa05b..6f91136f2cc8 100644
--- a/mm/vmalloc.c
+++ b/mm/vmallo
Remove unused argument from the __alloc_vmap_area() function.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..ea1b65fac599 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
function, it means if an empty node gets freed it is a BUG
thus is considered as faulty behaviour.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions
odes. Therefore we can say
that removing detached object is a bug in all cases.
v1->v2:
- update the commit message. [2] patch;
- fix typos in comments. [2] patch;
- do the "preload" for NUMA awareness. [2] patch;
Uladzislau Rezki (Sony) (4):
mm/vmap: remove &qu
On Fri, May 24, 2019 at 06:33:16PM +0800, Hillf Danton wrote:
>
> On Wed, 22 May 2019 17:09:37 +0200 Uladzislau Rezki (Sony) wrote:
> > /*
> > + * Preload this CPU with one extra vmap_area object to ensure
> > + * that we have it available when fit type of free are
On Wed, May 22, 2019 at 11:19:16AM -0700, Andrew Morton wrote:
> On Wed, 22 May 2019 17:09:39 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
> > function, it means if an empty node gets freed it is a BUG
&
On Wed, May 22, 2019 at 11:19:11AM -0700, Andrew Morton wrote:
> On Wed, 22 May 2019 17:09:38 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > It does not make sense to try to "unlink" the node that is
> > definitely not linked with a list nor tree. O
On Wed, May 22, 2019 at 11:19:04AM -0700, Andrew Morton wrote:
> On Wed, 22 May 2019 17:09:37 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > Introduce ne_fit_preload()/ne_fit_preload_end() functions
> > for preloading one extra vmap_area object to ensure that
&g
Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
function, it means if an empty node gets freed it is a BUG
thus is considered as faulty behaviour.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions
condition and high memory pressure.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 81 +---
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ea1b65fac599..5302e1b79c7b 100644
--- a/mm
points to an object that must
be linked.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5302e1b79c7b..89b8f44e8837 100644
--- a/mm/vmalloc.c
+++ b/mm/vmallo
Remove unused argument from the __alloc_vmap_area() function.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c42872ed82ac..ea1b65fac599 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
+Tobin C. Harding
On Wed, May 15, 2019 at 5:24 PM Uladzislau Rezki wrote:
>
> Hello, Andrew.
>
> > An earlier version of this patch was accused of crashing the kernel:
> >
> > https://lists.01.org/pipermail/lkp/2019-April/010004.html
> >
> > does the v
Hello, Andrew.
> An earlier version of this patch was accused of crashing the kernel:
>
> https://lists.01.org/pipermail/lkp/2019-April/010004.html
>
> does the v4 series address this?
I tried before to narrow down that crash but i did not succeed, so
i have never seen that before on my test
On Thu, Apr 18, 2019 at 03:10:33PM -0700, Andrew Morton wrote:
> On Thu, 18 Apr 2019 21:39:25 +0200 "Uladzislau Rezki (Sony)"
> wrote:
>
> > On my "Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz" system(12 CPUs)
> > i get the warning from the compiler about fra
cpumask_of() in set_cpus_allowed_ptr() as a second
argument.
Signed-off-by: Uladzislau Rezki (Sony)
---
lib/test_vmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
index 83cdcaa82bf6..f832b095afba 100644
--- a/lib/test_vmalloc.c
Hello, Roman.
>
> Reviewed-by: Roman Gushchin
>
> Thanks!
I appreciate your effort in reviewing to make it better.
Thank you!
--
Uladzislau Rezki
-off-by: Uladzislau Rezki (Sony)
Reviewed-by: Roman Gushchin
---
mm/vmalloc.c | 48
1 file changed, 48 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c6f9d0637464..a74e605e042f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -324,6
This macro adds some debug code to check that vmap allocations
are happened in ascending order.
By default this option is set to 0 and not active. It requires
recompilation of the kernel to activate it. Set to 1, compile
the kernel.
Signed-off-by: Uladzislau Rezki (Sony)
Reviewed-by: Roman
to the tree. Red-black tree allows efficiently
find a spot whereas a linked list provides a constant-time access
to previous and next blocks to check if merging can be done. In case
of merging of de-allocated memory chunk a large coalesced area is
created.
Complexity: ~O(log(N))
Signed-off-by: Uladzislau
vmalloc and other vmap allocations;
- use kmem_cache for vmap_area objects instead of own implementation;
- remove vmap cache globals;
- fix pcpu allocator on NUMA systems;
- now complexity is ~O(log(N)).
Uladzislau Rezki (Sony) (3):
mm/vmap: keep track of free blocks for vmap allocation
mm/vmap:
> > >
> > > Do we need this change?
> > >
> > This patch does not tend to refactor the code. I have removed extra empty
> > lines because i touched the code around. I can either keep that change or
> > remove it. What is your opinion?
>
> Usually it's better to separate cosmetic changes from
> > +#if DEBUG_AUGMENT_PROPAGATE_CHECK
> > +static void
> > +augment_tree_propagate_do_check(struct rb_node *n)
> > +{
> > + struct vmap_area *va;
> > + struct rb_node *node;
> > + unsigned long size;
> > + bool found = false;
> > +
> > + if (n == NULL)
> > + return;
> > +
> >
a linked list provides a constant-time access
> > to previous and next blocks to check if merging can be done. In case
> > of merging of de-allocated memory chunk a large coalesced area is
> > created.
> >
> > Complexity: ~O(log(N))
> >
> > Signed-off-by: Uladzislau Rezki
This macro adds some debug code to check that vmap allocations
are happened in ascending order.
By default this option is set to 0 and not active. It requires
recompilation of the kernel to activate it. Set to 1, compile
the kernel.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 43
debug code to separate patches;
Changes in v2
-
- do not distinguish vmalloc and other vmap allocations;
- use kmem_cache for vmap_area objects instead of own implementation;
- remove vmap cache globals;
- fix pcpu allocator on NUMA systems;
- now complexity is ~O(log(N)).
Uladzislau Rezki (
: ~O(log(N))
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/vmalloc.h |6 +-
mm/vmalloc.c| 1004 +++
2 files changed, 762 insertions(+), 248 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 39
-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3adbad3fb6c1..1449a8c43aa2 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -322,6 +322,8 @@ unsigned long
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
> > > further tes
Hello, Andrew.
>
> It's a lot of new code. I t looks decent and I'll toss it in there for
> further testing. Hopefully someone will be able to find the time for a
> detailed review.
>
I have got some proposals and comments about simplifying the code a bit.
So i am about to upload the v3 for
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
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
i am not sure if it is worth it
or not.
> Some small nits/questions below.
>
> >
> > Signed-off-by: Uladzislau Rezki (Sony)
> > ---
> > include/linux/vmalloc.h |6 +-
> > mm/vmalloc.c| 1109
> >
On Thu, Mar 21, 2019 at 03:01:06PM -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2019 20:03:26 +0100 "Uladzislau Rezki (Sony)"
> wrote:
>
> > Hello.
> >
> > This is the v2 of the https://lkml.org/lkml/2018/10/19/786 rework. Instead
> > of
> &
t distinguish vmalloc and other vmap allocations;
- use kmem_cache for vmap_area objects instead of own implementation;
- remove vmap cache globals;
- fix pcpu allocator on NUMA systems;
- now complexity is ~O(log(N)).
Appreciate for any comments and your time spent on it.
Uladzislau Rezki (Sony
: ~O(log(N))
Signed-off-by: Uladzislau Rezki (Sony)
---
include/linux/vmalloc.h |6 +-
mm/vmalloc.c| 1109 ---
2 files changed, 871 insertions(+), 244 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 39
> > >
> > > I'm a bit concerned that this will introduce the latency back if
> > > vmap_lazy_nr
> > > is greater than half of lazy_max_pages(). Which IIUC will be more likely
> > > if
> > > the number of CPUs is large.
> > >
> > The threshold that we establish is two times more than
Hello, Matthew.
On Mon, Feb 04, 2019 at 05:33:00AM -0800, Matthew Wilcox wrote:
> On Mon, Feb 04, 2019 at 11:49:56AM +0100, Uladzislau Rezki wrote:
> > On Fri, Feb 01, 2019 at 01:45:28PM +0100, Michal Hocko wrote:
> > > On Thu 31-01-19 17:24:52, Uladzislau Rezki (Sony) wrote:
&g
Hello, Michal.
On Fri, Feb 01, 2019 at 01:45:28PM +0100, Michal Hocko wrote:
> On Thu 31-01-19 17:24:52, Uladzislau Rezki (Sony) wrote:
> > vmap_lazy_nr variable has atomic_t type that is 4 bytes integer
> > value on both 32 and 64 bit systems. lazy_max_pages() deals with
>
vmap_lazy_nr variable has atomic_t type that is 4 bytes integer
value on both 32 and 64 bit systems. lazy_max_pages() deals with
"unsigned long" that is 8 bytes on 64 bit system, thus vmap_lazy_nr
should be 8 bytes on 64 bit as well.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmal
On Mon, Jan 28, 2019 at 05:45:28PM -0500, Joel Fernandes wrote:
> On Thu, Jan 24, 2019 at 12:56:48PM +0100, Uladzislau Rezki (Sony) wrote:
> > commit 763b218ddfaf ("mm: add preempt points into
> > __purge_vmap_area_lazy()")
> >
> > introduced some p
On Mon, Jan 28, 2019 at 12:04:29PM -0800, Andrew Morton wrote:
> On Thu, 24 Jan 2019 12:56:48 +0100 "Uladzislau Rezki (Sony)"
> wrote:
>
> > commit 763b218ddfaf ("mm: add preempt points into
> > __purge_vmap_area_lazy()")
> >
> > i
they are pretty ready to go with, unless
there are any comments from you.
Thank you!
--
Vlad Rezki
Uladzislau Rezki (Sony) (2):
mm/vmalloc: fix kernel BUG at mm/vmalloc.c:512!
mm: add priority threshold to __purge_vmap_area_lazy()
mm/vmalloc.c | 24 +---
1 file changed, 17
address is within vstart/vend
range.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1c512fff8a56..fb4fb5fcee74 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -498,7 +498,11 @@ static
to completely blocking of logic that frees vmap areas
in the __purge_vmap_area_lazy() function.
Establish a threshold passing which the freeing is prioritized
back over allocation creating a balance between each other.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 18 --
1
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
add basic vmalloc smoke test to the "run_vmtests" suite.
Signed-off-by: Uladzislau Rezki (Sony)
---
tools/testing/selftests/vm/run_vmtests | 16 +++
tools/testing/selftests/vm/test_vmalloc.sh | 176 +
2 files changed, 192 insertions(+)
create mode
check
of vmalloc allocator.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 97d4b25d0373..1c512fff8a56 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1768,6 +1768,15 @@ void
be like:
modprobe vmalloc_test test_repeat_count=30
Expected results are the system is alive, there are no any BUG_ONs or Kernel
Panics the tests are completed, no memory leaks.
Signed-off-by: Uladzislau Rezki (Sony)
---
lib/Kconfig.debug | 12 ++
lib/Makefile | 1 +
lib/test_vmalloc.c
__vmalloc_node_range() is exported if CONFIG_TEST_VMALLOC_MODULE=m
- Integrate vmalloc test suite into tools/testing/selftests/vm
I think it is ready to go with, unless there are more requests or comments.
Thank you in advance.
Uladzislau Rezki (Sony) (3):
vmalloc: export __vmalloc_node_range
add basic vmalloc smoke test to the "run_vmtests" suite.
Signed-off-by: Uladzislau Rezki (Sony)
---
tools/testing/selftests/vm/run_vmtests | 16 +++
tools/testing/selftests/vm/test_vmalloc.sh | 176 +
2 files changed, 192 insertions(+)
create mode
be like:
modprobe vmalloc_test test_repeat_count=30
Expected results are the system is alive, there are no any BUG_ONs or Kernel
Panics the tests are completed, no memory leaks.
Signed-off-by: Uladzislau Rezki (Sony)
---
lib/Kconfig.debug | 12 ++
lib/Makefile | 1 +
lib/test_vmalloc.c
please RFC v3.
Thank you.
Uladzislau Rezki (Sony) (3):
vmalloc: export __vmalloc_node_range for CONFIG_TEST_VMALLOC_MODULE
vmalloc: add test driver to analyse vmalloc allocator
selftests/vm: add script helper for CONFIG_TEST_VMALLOC_MODULE
lib/Kconfig.debug | 12 +
lib
401 - 500 of 601 matches
Mail list logo
