2001-10-05 11:33:58

by BALBIR SINGH

[permalink] [raw]
Subject: [RFC][PATCH]Small Minor optimization to kmem_cache_estimate

A small minor optimization in kmem_cache_estimate() slab.c

The patch below saves some CPU cycles, especially when the value of size
is small. This is against 2.4.2-2.

--- slab.c.org Fri Oct 5 16:09:39 2001
+++ slab.c Fri Oct 5 16:46:34 2001
@@ -386,10 +386,10 @@
base = sizeof(slab_t);
extra = sizeof(kmem_bufctl_t);
}
- i = 0;
+ i = (wastage - base)/(size + extra);
while (i*size + L1_CACHE_ALIGN(base+i*extra) <= wastage)
i++;
- if (i > 0)
+ while (i*size + L1_CACHE_ALIGN(base+i*extra) > wastage)
i--;

instead of looping through to get the right value, we make a guess
(mathematically) and move a bit to get the correct value.

Hey, I remember reading the Newton-Raphson method in school.

I verified the number of objects per slab is the same in both cases.
This patch may not improve the performance of your CPU by a great amount,
but when there is a faster way to do things, why live with the slower one.

NOTE: The code hardly does one loop in both the while statements.

Comments,
Balbir



Attachments:
Wipro_Disclaimer.txt (853.00 B)

2001-10-05 23:44:40

by David Miller

[permalink] [raw]
Subject: Re: [RFC][PATCH]Small Minor optimization to kmem_cache_estimate

From: "BALBIR SINGH" <[email protected]>
Date: Fri, 05 Oct 2001 17:04:21 +0530

I verified the number of objects per slab is the same in both cases.
This patch may not improve the performance of your CPU by a great amount,
but when there is a faster way to do things, why live with the slower one.

Since this code only occurs during SLAB creation, you estimation on
CPU savings is correct.

Why live with it? Less changes to verify would be one reason :-)

Franks a lot,
David S. Miller
[email protected]