mm/vmalloc.c: correct lazy_max_pages() return value

PATCH Superseded zijun_hu 4 participants 10 messages Sep 21, 2016 – Sep 23, 2016

Subsystems (2)

Memory management vmalloc

lore

Share & tools

lore

zijun_hu

author

2016-09-21 04:28 UTC #0 lore raw

PATCH 3/5 mm/vmalloc.c: correct lazy_max_pages() return value

From: zijun_hu <[email protected]>

correct lazy_max_pages() return value if the number of online CPUs is power of 2

Signed-off-by zijun_hu <[email protected]>

---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

mm/vmalloc.c +3 -1

index a125ae8..2804224 100644
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)
 {
 	unsigned int log;
 
-	log = fls(num_online_cpus());
+	log = num_online_cpus();
+	if (log > 1)
+		log = (unsigned int)get_count_order(log);
 
 	return log * (32UL * 1024 * 1024 / PAGE_SIZE);
 }

Signature · 1 line

1.9.1

David Rientjes

2016-09-21 21:21 UTC #1 lore raw

Quoted 15 lines · zijun_hu

From: zijun_hu <[email protected]>
correct lazy_max_pages() return value if the number of online CPUs is power of 2
Signed-off-by zijun_hu <[email protected]>
---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/vmalloc.c +0 -0
index a125ae8..2804224 100644

mm/vmalloc.c static unsigned long lazy_max_pages(void) · line 602

Quoted 10 lines

mm/vmalloc.c +3 -1

@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)
 {
 	unsigned int log;
 
-	log = fls(num_online_cpus());
+	log = num_online_cpus();
+	if (log > 1)
+		log = (unsigned int)get_count_order(log);
 
 	return log * (32UL * 1024 * 1024 / PAGE_SIZE);
 }

The implementation of lazy_max_pages() is somewhat arbitrarily defined, the existing approximation has been around for eight years and num_online_cpus() isn't intended to be rounded up to the next power of 2. I'd be inclined to just leave it as it is.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

zijun_hu

author

2016-09-21 23:30 UTC #2 lore raw

Quoted 25 lines · David Rientjes

Quoted 23 lines · zijun_hu
From: zijun_hu <[email protected]>
correct lazy_max_pages() return value if the number of online CPUs is power of 2
Signed-off-by zijun_hu <[email protected]>
---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/vmalloc.c +3 -1
index a125ae8..2804224 100644
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)
 {
 	unsigned int log;
 
-	log = fls(num_online_cpus());
+	log = num_online_cpus();
+	if (log > 1)
+		log = (unsigned int)get_count_order(log);
 

Quoted 8 lines

mm/vmalloc.c static unsigned long lazy_max_pages(void) · line 602
Quoted 2 lines
mm/vmalloc.c +0 -0
 	return log * (32UL * 1024 * 1024 / PAGE_SIZE);
 }
The implementation of lazy_max_pages() is somewhat arbitrarily defined, the existing approximation has been around for eight years and num_online_cpus() isn't intended to be rounded up to the next power of 2. I'd be inclined to just leave it as it is.

do i understand the intent in current code logic as below ? [8, 15) roundup to 16?
[32, 63) roundup to 64?

David Rientjes

2016-09-22 00:35 UTC #3 lore raw

Quoted 34 lines · zijun_hu

Quoted 25 lines · David Rientjes
Quoted 23 lines · zijun_hu
From: zijun_hu <[email protected]>
correct lazy_max_pages() return value if the number of online CPUs is power of 2
Signed-off-by zijun_hu <[email protected]>
---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/vmalloc.c +3 -1
index a125ae8..2804224 100644
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)
 {
 	unsigned int log;
 
-	log = fls(num_online_cpus());
+	log = num_online_cpus();
+	if (log > 1)
+		log = (unsigned int)get_count_order(log);
 
Quoted 8 lines
mm/vmalloc.c static unsigned long lazy_max_pages(void) · line 602
Quoted 2 lines
mm/vmalloc.c +0 -0
 	return log * (32UL * 1024 * 1024 / PAGE_SIZE);
 }
The implementation of lazy_max_pages() is somewhat arbitrarily defined, the existing approximation has been around for eight years and num_online_cpus() isn't intended to be rounded up to the next power of 2. I'd be inclined to just leave it as it is.

Quoted 4 lines

do i understand the intent in current code logic as below ? [8, 15) roundup to 16?
[32, 63) roundup to 64?

The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.

zijun_hu

author

2016-09-22 01:15 UTC #4 lore raw

Quoted 41 lines · David Rientjes

Quoted 34 lines · zijun_hu
Quoted 25 lines · David Rientjes
Quoted 23 lines · zijun_hu
From: zijun_hu <[email protected]>
correct lazy_max_pages() return value if the number of online CPUs is power of 2
Signed-off-by zijun_hu <[email protected]>
---
 mm/vmalloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/vmalloc.c +3 -1
index a125ae8..2804224 100644
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)
 {
 	unsigned int log;
 
-	log = fls(num_online_cpus());
+	log = num_online_cpus();
+	if (log > 1)
+		log = (unsigned int)get_count_order(log);
 
Quoted 8 lines
mm/vmalloc.c static unsigned long lazy_max_pages(void) · line 602
Quoted 2 lines
mm/vmalloc.c +0 -0
 	return log * (32UL * 1024 * 1024 / PAGE_SIZE);
 }
The implementation of lazy_max_pages() is somewhat arbitrarily defined, the existing approximation has been around for eight years and num_online_cpus() isn't intended to be rounded up to the next power of 2. I'd be inclined to just leave it as it is.
Quoted 4 lines
do i understand the intent in current code logic as below ? [8, 15) roundup to 16?
[32, 63) roundup to 64?

Quoted 7 lines

The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.

my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment

if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance

my change : (32, 64] -> 64

	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128

Michal Hocko

2016-09-22 12:37 UTC #5 lore raw

Quoted 1 line · zijun_hu

On 09/22/2016 08:35 AM, David Rientjes wrote:

[...]

Quoted 10 lines

Quoted 7 lines
The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.
my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment

Quoted 8 lines

if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance
my change : (32, 64] -> 64
	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128

You still completely failed to explain _why_ this is an improvement/fix or why it matters. This all should be in the changelog.

Signature · 2 lines

Michal Hocko
SUSE Labs

zijun_hu

author

2016-09-22 16:30 UTC #6 lore raw

Quoted 17 lines · Michal Hocko

Quoted 1 line · zijun_hu
On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
Quoted 14 lines
Quoted 7 lines
The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.
my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment
if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance

Quoted 8 lines

Quoted 4 lines
my change : (32, 64] -> 64
	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128
You still completely failed to explain _why_ this is an improvement/fix or why it matters. This all should be in the changelog.

Hi npiggin,
could you give some comments for this patch since lazy_max_pages() is introduced by you

my patch is based on the difference between fls() and get_count_order() mainly the difference between fls() and get_count_order() will be shown below more MM experts maybe help to decide which is more suitable

if parameter > 1, both have different return value only when parameter is power of two, for example

fls(32) = 6 VS get_count_order(32) = 5
fls(33) = 6 VS get_count_order(33) = 6
fls(63) = 6 VS get_count_order(63) = 6
fls(64) = 7 VS get_count_order(64) = 6

@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void)

{ 
    unsigned int log;

-    log = fls(num_online_cpus()); 
+    log = num_online_cpus(); 
+    if (log > 1)

+ log = (unsigned int)get_count_order(log);

    return log * (32UL * 1024 * 1024 / PAGE_SIZE); 
}

Nicholas Piggin

2016-09-23 03:30 UTC #7 lore raw

Quoted 45 lines · On Fri, 23 Sep 2016 00:30:20 +0800 zijun_hu <[email protected]> wrote:

Quoted 17 lines · Michal Hocko
Quoted 1 line · zijun_hu
On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
Quoted 14 lines
Quoted 7 lines
The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.
my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment
if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance
Quoted 8 lines
Quoted 4 lines
my change : (32, 64] -> 64
	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128  
You still completely failed to explain _why_ this is an improvement/fix or why it matters. This all should be in the changelog.
Hi npiggin,
could you give some comments for this patch since lazy_max_pages() is introduced by you
my patch is based on the difference between fls() and get_count_order() mainly the difference between fls() and get_count_order() will be shown below more MM experts maybe help to decide which is more suitable
if parameter > 1, both have different return value only when parameter is power of two, for example
fls(32) = 6 VS get_count_order(32) = 5
fls(33) = 6 VS get_count_order(33) = 6
fls(63) = 6 VS get_count_order(63) = 6
fls(64) = 7 VS get_count_order(64) = 6

Review static unsigned long lazy_max_pages(void) · line 602

Quoted 10 lines

(quoted diff) +3 -1

@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void) 
 { 
    unsigned int log; 
 
-    log = fls(num_online_cpus()); 
+    log = num_online_cpus(); 
+    if (log > 1) 
+        log = (unsigned int)get_count_order(log); 
 
    return log * (32UL * 1024 * 1024 / PAGE_SIZE); 
 }

To be honest, I don't think I chose it with a lot of analysis. It will depend on the kernel usage patterns, the arch code, and the CPU microarchitecture, all of which would have changed significantly.

I wouldn't bother changing it unless you do some benchmarking on different system sizes to see where the best performance is. (If performance is equal, fewer lazy pages would be better.)

Good to see you taking a look at this vmalloc stuff. Don't be discouraged if you run into some dead ends.

Thanks,
Nick

zijun_hu

author

2016-09-23 05:00 UTC #8 lore raw

Quoted 68 lines · Nicholas Piggin

Quoted 45 lines · On Fri, 23 Sep 2016 00:30:20 +0800 zijun_hu <[email protected]> wrote:
Quoted 17 lines · Michal Hocko
Quoted 1 line · zijun_hu
On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
Quoted 14 lines
Quoted 7 lines
The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.
my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment
if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance
Quoted 8 lines
Quoted 4 lines
my change : (32, 64] -> 64
	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128  
You still completely failed to explain _why_ this is an improvement/fix or why it matters. This all should be in the changelog.
Hi npiggin,
could you give some comments for this patch since lazy_max_pages() is introduced by you
my patch is based on the difference between fls() and get_count_order() mainly the difference between fls() and get_count_order() will be shown below more MM experts maybe help to decide which is more suitable
if parameter > 1, both have different return value only when parameter is power of two, for example
fls(32) = 6 VS get_count_order(32) = 5
fls(33) = 6 VS get_count_order(33) = 6
fls(63) = 6 VS get_count_order(63) = 6
fls(64) = 7 VS get_count_order(64) = 6
Review static unsigned long lazy_max_pages(void) · line 602
Quoted 10 lines
(quoted diff) +3 -1
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void) 
 { 
    unsigned int log; 
 
-    log = fls(num_online_cpus()); 
+    log = num_online_cpus(); 
+    if (log > 1) 
+        log = (unsigned int)get_count_order(log); 
 
    return log * (32UL * 1024 * 1024 / PAGE_SIZE); 
 } 
To be honest, I don't think I chose it with a lot of analysis. It will depend on the kernel usage patterns, the arch code, and the CPU microarchitecture, all of which would have changed significantly.
I wouldn't bother changing it unless you do some bench marking on different system sizes to see where the best performance is. (If performance is equal, fewer lazy pages would be better.)

Quoted 6 lines

Good to see you taking a look at this vmalloc stuff. Don't be discouraged if you run into some dead ends.
Thanks,
Nick

thanks for your reply
please don't pay attention to this patch any more since i don't have condition to do many test and comparison

i just feel my change maybe be consistent with operation of rounding up to power of 2

Nicholas Piggin

2016-09-23 07:27 UTC #9 lore raw

Quoted 75 lines · On Fri, 23 Sep 2016 13:00:35 +0800 zijun_hu <[email protected]> wrote:

Quoted 68 lines · Nicholas Piggin
Quoted 45 lines · On Fri, 23 Sep 2016 00:30:20 +0800 zijun_hu <[email protected]> wrote:
Quoted 17 lines · Michal Hocko
Quoted 1 line · zijun_hu
On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
Quoted 14 lines
Quoted 7 lines
The intent is as it is implemented; with your change, lazy_max_pages() is potentially increased depending on the number of online cpus. This is only a heuristic, changing it would need justification on why the new value is better. It is opposite to what the comment says: "to be conservative and not introduce a big latency on huge systems, so go with a less aggressive log scale." NACK to the patch.
my change potentially make lazy_max_pages() decreased not increased, i seems conform with the comment
if the number of online CPUs is not power of 2, both have no any difference otherwise, my change remain power of 2 value, and the original code rounds up to next power of 2 value, for instance
Quoted 8 lines
Quoted 4 lines
my change : (32, 64] -> 64
	     32 -> 32, 64 -> 64
the original code: [32, 63) -> 64
                   32 -> 64, 64 -> 128    
You still completely failed to explain _why_ this is an improvement/fix or why it matters. This all should be in the changelog.
Hi npiggin,
could you give some comments for this patch since lazy_max_pages() is introduced by you
my patch is based on the difference between fls() and get_count_order() mainly the difference between fls() and get_count_order() will be shown below more MM experts maybe help to decide which is more suitable
if parameter > 1, both have different return value only when parameter is power of two, for example
fls(32) = 6 VS get_count_order(32) = 5
fls(33) = 6 VS get_count_order(33) = 6
fls(63) = 6 VS get_count_order(63) = 6
fls(64) = 7 VS get_count_order(64) = 6
Review static unsigned long lazy_max_pages(void) · line 602
Quoted 10 lines
(quoted diff) +3 -1
@@ -594,7 +594,9 @@ static unsigned long lazy_max_pages(void) 
 { 
    unsigned int log; 
 
-    log = fls(num_online_cpus()); 
+    log = num_online_cpus(); 
+    if (log > 1) 
+        log = (unsigned int)get_count_order(log); 
 
    return log * (32UL * 1024 * 1024 / PAGE_SIZE); 
 } 
To be honest, I don't think I chose it with a lot of analysis. It will depend on the kernel usage patterns, the arch code, and the CPU microarchitecture, all of which would have changed significantly.
I wouldn't bother changing it unless you do some bench marking on different system sizes to see where the best performance is. (If performance is equal, fewer lazy pages would be better.)
Quoted 6 lines
Good to see you taking a look at this vmalloc stuff. Don't be discouraged if you run into some dead ends.
Thanks,
Nick

Quoted 6 lines

thanks for your reply
please don't pay attention to this patch any more since i don't have condition to do many test and comparison
i just feel my change maybe be consistent with operation of rounding up to power of 2

You could be right about that, but in cases like this, existing code probably trumps original comments or intention.

What I mean is that it's a heuristic anyway, so the current behaviour is what has been used and tested for a long time. Therefore any change would need to be justified by showing it's an improvement.

I'm sure the existing size is not perfect, but we don't know whether your change would be an improvement in practice. Does that make sense?

Thanks,
Nick