From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auyXK-00053f-Iv for qemu-devel@nongnu.org; Tue, 26 Apr 2016 04:40:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auyXH-000861-DZ for qemu-devel@nongnu.org; Tue, 26 Apr 2016 04:40:02 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:36892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auyXH-00085j-5b for qemu-devel@nongnu.org; Tue, 26 Apr 2016 04:39:59 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Apr 2016 09:39:57 +0100 References: <1461633961-31713-1-git-send-email-zhoujie2011@cn.fujitsu.com> <571F1CA4.70306@de.ibm.com> <571F262A.3020705@cn.fujitsu.com> From: Christian Borntraeger Message-ID: <571F2957.8050805@de.ibm.com> Date: Tue, 26 Apr 2016 10:39:51 +0200 MIME-Version: 1.0 In-Reply-To: <571F262A.3020705@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] net/tap: Allocating Large sized arrays to heap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhou Jie , qemu-devel@nongnu.org Cc: qemu-trivial@nongnu.org, jasowang@redhat.com On 04/26/2016 10:26 AM, Zhou Jie wrote: > On 2016/4/26 15:45, Christian Borntraeger wrote: >> On 04/26/2016 03:26 AM, Zhou Jie wrote: >>> net_init_tap has a huge stack usage of 8192 bytes approx. >>> Moving large arrays to heap to reduce stack usage. >> >> I am wondering. Why is 8k a problem for a user space program? > For 64bit machine it will be 16k. Even that does not matter. The userspace stack is on most Linuxes somewhere between 8MB and unlimited. Reducing stack usage makes sense for the kernel as the kernel stack is limited to 8k or 16k. For userspace it does also make sense for things like thread stacks or coroutines, where we have a much smaller stack (well, still 1MB for coroutines as of today) and if we are not on a hot path. Regarding hot pathes: There is a reason why people use jemalloc or tcmalloc. The allocators try to use per-thread arena, but still each allocation might cause significant cross cpu/thread traffic. And having a allocator that scales well across many CPUs is not trivial. > >> Please note that malloc/new like allocations are much more expensive >> than stack allocation in terms of performance. This does not matter >> here, but in your other patch that deals with the xmit function, I would >> not be surprised if that actually harms performance. > OK. I will note it. > > Sincerely, > Zhou Jie > >> >> Christian >> >> >> >>> >>> Signed-off-by: Zhou Jie >>> --- >>> net/tap.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/net/tap.c b/net/tap.c >>> index 740e8a2..49817c7 100644 >>> --- a/net/tap.c >>> +++ b/net/tap.c >>> @@ -769,8 +769,8 @@ int net_init_tap(const NetClientOptions *opts, const char *name, >>> return -1; >>> } >>> } else if (tap->has_fds) { >>> - char *fds[MAX_TAP_QUEUES]; >>> - char *vhost_fds[MAX_TAP_QUEUES]; >>> + char **fds = g_new(char *, MAX_TAP_QUEUES); >>> + char **vhost_fds = g_new(char *, MAX_TAP_QUEUES); >>> int nfds, nvhosts; >>> >>> if (tap->has_ifname || tap->has_script || tap->has_downscript || >>> @@ -818,6 +818,8 @@ int net_init_tap(const NetClientOptions *opts, const char *name, >>> return -1; >>> } >>> } >>> + g_free(fds); >>> + g_free(vhost_fds); >>> } else if (tap->has_helper) { >>> if (tap->has_ifname || tap->has_script || tap->has_downscript || >>> tap->has_vnet_hdr || tap->has_queues || tap->has_vhostfds) { >>> >> >> >> >> >