Skip to contentSkip to conversation

mm/zsmalloc: avoid unnecessary iteration when freeing size_class

PATCH In review Ganesh Mahendran 2 participants 4 messages Jan 24, 2015 – Feb 2, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mm/zsmalloc: avoid unnecessary iteration when freeing size_class

The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0. So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1) to i, instead of from 0 to (zs_size_classes - 1)

---
 mm/zsmalloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/zsmalloc.c +2 -2
index 16617e9..e6fa3da 100644
@@ -1433,12 +1433,12 @@ void zs_destroy_pool(struct zs_pool *pool)
 
 	zs_pool_stat_destroy(pool);
 
-	for (i = 0; i < zs_size_classes; i++) {
+	for (i = zs_size_classes - 1; i >= 0; i--) {
 		int fg;
 		struct size_class *class = pool->size_class[i];
 
 		if (!class)
-			continue;
+			break;
 
 		if (class->index != i)
 			continue;
Signature · 7 lines
1.7.9.5

--
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>
#1 lore raw

ping.

2015-01-24 21:50 GMT+08:00 Ganesh Mahendran <[email protected]>:

Quoted 3 lines

The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0. So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1) to i, instead of from 0 to (zs_size_classes - 1)

No functionality has been changed. This patch just avoids some necessary iteration.

Thanks.

Quoted 28 lines
---
 mm/zsmalloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/zsmalloc.c +2 -3
index 16617e9..e6fa3da 100644
@@ -1433,12 +1433,12 @@ void zs_destroy_pool(struct zs_pool *pool)
 
        zs_pool_stat_destroy(pool);
 
-       for (i = 0; i < zs_size_classes; i++) {
+       for (i = zs_size_classes - 1; i >= 0; i--) {
                int fg;
                struct size_class *class = pool->size_class[i];
 
                if (!class)
-                       continue;
+                       break;
 
                if (class->index != i)
                        continue;
--
Quoted 2 lines

1.7.9.5

--
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>

maintainer
#2 lore raw

Hello Ganesh,

Quoted 9 lines · Ganesh Mahendran

ping.

2015-01-24 21:50 GMT+08:00 Ganesh Mahendran <[email protected]>:

Quoted 3 lines

The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0. So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1) to i, instead of from 0 to (zs_size_classes - 1)

No functionality has been changed. This patch just avoids some necessary iteration.

Sorry for the delay. Did you saw any performance problem? I know it would be better than old but your assumption depends on the implmentation of zs_create_pool so if we changes(for example, revert 9eec4cd if compaction works well), your patch would be void. If it's not a critical, I'd like to remain it as generic and doesn't contaminate git-blame.

Thanks.

Signature · 8 lines
Kind regards,
Minchan Kim

--
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>
#3 lore raw

Hello Minchan:

2015-02-02 9:09 GMT+08:00 Minchan Kim <[email protected]>:

Quoted 10 lines

Hello Ganesh,

Quoted 7 lines · Ganesh Mahendran

ping.

2015-01-24 21:50 GMT+08:00 Ganesh Mahendran <[email protected]>:

Quoted 3 lines

The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0. So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1) to i, instead of from 0 to (zs_size_classes - 1)

Quoted 7 lines
Quoted 2 lines

No functionality has been changed. This patch just avoids some necessary iteration.

Sorry for the delay. Did you saw any performance problem? I know it would be better than old but your assumption depends on the implmentation of zs_create_pool so if we changes(for example, revert 9eec4cd if compaction works well), your patch would be void.

Yes, You are right.
Thanks so much.

Quoted 8 lines

If it's not a critical, I'd like to remain it as generic and doesn't contaminate git-blame.

Thanks.

--
Kind regards,
Minchan Kim

--
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>