linux-kernel - Re: [PATCH RFC V2 2/2] net: Optimize snmp stat aggregation by walking all the percpu data at once

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1440806774.8932.94.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 28 Aug 2015 17:06:14 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	David Miller <davem@...emloft.net>,
	raghavendra.kt@...ux.vnet.ibm.com, edumazet@...gle.com,
	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, jiri@...nulli.us, hannes@...essinduktion.org,
	tom@...bertland.com, azhou@...ira.com, ebiederm@...ssion.com,
	ipm@...rality.org.uk, nicolas.dichtel@...nd.com,
	serge.hallyn@...onical.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, anton@....ibm.com,
	nacc@...ux.vnet.ibm.com, srikar@...ux.vnet.ibm.com
Subject: Re: [PATCH RFC V2 2/2] net: Optimize snmp stat aggregation by
 walking all the percpu data at once

On Fri, 2015-08-28 at 16:12 -0700, Joe Perches wrote:

> Generally true.  It's always difficult to know how much
> stack has been consumed though and smaller stack frames
> are generally better.

Calling kmalloc(288, GFP_KERNEL) might use way more than 288 bytes in
kernel stack on 64 bit arch.

__slab_alloc() itself for example uses 208 bytes on stack, so add all
others, and you might go above 500 bytes.
 
So for a _leaf_ function, it is better to declare an automatic variable,
as you in fact reduce max stack depth.

Not only it uses less kernel stack, it is also way faster, as you avoid
kmalloc()/kfree() overhead and reuse probably already hot cache lines in
kernel stack.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/