This series contains 2 simple cleanup patches to slightly reduce memory
and performance overhead.
Waiman Long (2):
mm/kmemleak: Compact kmemleak_object further
mm/kmemleak: Disable KASAN instrumentation in kmemleak
mm/Makefile | 1 +
mm/kmemleak.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
2.39.3
With commit 56a61617dd22 ("mm: use stack_depot for recording kmemleak's
backtrace"), the size of kmemleak_object has been reduced by 128 bytes
for 64-bit arches. The replacement "depot_stack_handle_t trace_handle"
is actually just 4 bytes long leaving a hole of 4 bytes. By moving up
trace_handle to another existing 4-byte hold, we can save 8 more bytes
from kmemleak_object reducing its overall size from 248 to 240 bytes.
Signed-off-by: Waiman Long <[email protected]>
---
mm/kmemleak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 4f58f6170cdf..0114a694e520 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -158,9 +158,9 @@ struct kmemleak_object {
int count;
/* checksum for detecting modified objects */
u32 checksum;
+ depot_stack_handle_t trace_handle;
/* memory ranges to be scanned inside an object (empty for all) */
struct hlist_head area_list;
- depot_stack_handle_t trace_handle;
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
--
2.39.3
Kmemleak ia a memory leak checker. KASAN is also a memory checker but
it focuses more on finding out-of-bounds and use-after-free bugs. Since
kmemleak is inherently slow especially on systems with large number of
CPUs, adding KASAN instrumentation will make it slower even more. As
kmemleak is not for production use, the utility of enabling KASAN there
is questionable.
This patch disables KASAN instrumentation for configurations that
enable both of them to slightly reduce performance overhead.
Signed-off-by: Waiman Long <[email protected]>
---
mm/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/Makefile b/mm/Makefile
index e4b5b75aaec9..fc0f9a63a61e 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -5,6 +5,7 @@
KASAN_SANITIZE_slab_common.o := n
KASAN_SANITIZE_slub.o := n
+KASAN_SANITIZE_kmemleak.o := n
KCSAN_SANITIZE_kmemleak.o := n
# These produce frequent data race reports: most of them are due to races on
--
2.39.3
On Thu, Mar 07, 2024 at 02:05:47PM -0500, Waiman Long wrote:
> With commit 56a61617dd22 ("mm: use stack_depot for recording kmemleak's
> backtrace"), the size of kmemleak_object has been reduced by 128 bytes
> for 64-bit arches. The replacement "depot_stack_handle_t trace_handle"
> is actually just 4 bytes long leaving a hole of 4 bytes. By moving up
> trace_handle to another existing 4-byte hold, we can save 8 more bytes
> from kmemleak_object reducing its overall size from 248 to 240 bytes.
>
> Signed-off-by: Waiman Long <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
On Thu, Mar 07, 2024 at 02:05:48PM -0500, Waiman Long wrote:
> Kmemleak ia a memory leak checker. KASAN is also a memory checker but
> it focuses more on finding out-of-bounds and use-after-free bugs. Since
> kmemleak is inherently slow especially on systems with large number of
> CPUs, adding KASAN instrumentation will make it slower even more. As
> kmemleak is not for production use, the utility of enabling KASAN there
> is questionable.
>
> This patch disables KASAN instrumentation for configurations that
> enable both of them to slightly reduce performance overhead.
>
> Signed-off-by: Waiman Long <[email protected]>
Acked-by: Catalin Marinas <[email protected]>