From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: decrease the memory init time with many hugepages setup Date: Thu, 02 Apr 2015 14:55:53 +0200 Message-ID: <2705739.59RNFm1sab@xps13> References: <1427974230-8572-1-git-send-email-jerry.lilijun@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: jerry.lilijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <1427974230-8572-1-git-send-email-jerry.lilijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2015-04-02 19:30, jerry.lilijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org: > From: Lilijun > > In the function map_all_hugepages(), hugepage memory is truly allocated by > memset(virtaddr, 0, hugepage_sz). Then it costs about 40s to finish the > dpdk memory initialization when 40000 2M hugepages are setup in host os. Yes it's something we should try to reduce. > In fact we can only write one byte to finish the allocation. Isn't it a security hole? This article speaks about "prezeroing optimizations" in Linux kernel: http://landley.net/writing/memory-faq.txt