From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id 937A98DAC for ; Mon, 23 Nov 2015 05:07:33 +0100 (CET) Received: by pacej9 with SMTP id ej9so177917084pac.2 for ; Sun, 22 Nov 2015 20:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=rFhIRfwqvGPa5dC58Y+I5jaic88IbzIVxSk+CZkfVhM=; b=UeqyUJcqFlgwnxUiLwhmPPAqpxp33tMkSrpG2fzYV4F9qCRZm9gRGtGhhup5EzVEiR dlT1V9Q9N659hemIN1n5aFDB1EIoe2C1gIWdPiweub1hJmsfOSzA2vNGYDmL0HhAkWzA kDoJ9fAWEWFg9TihdXJtx06EikqDBzrGGOV7pcxJLVNlczTYwV8BOOVf7xO+kIX6wb3e bE0oVhY1gZA7NMD8lG0YE+DKTIvVh8MvyNXw2n50PWd+6rYo2yas6bkheaMRbzTrf8iv Eoq9175mn8xqf3LeiniTadUhnjALbTLu9gGOeiOCDvaS4L9hb+vJ3tnFqXLBb1TBSB0V TWkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=rFhIRfwqvGPa5dC58Y+I5jaic88IbzIVxSk+CZkfVhM=; b=SCITqGd1TraalPiZOJsXpuDMHf0lHzLXQEbopWTl56RwmRzpVB2IQpGArj9ct+js4F bhOaBWVXAjo53IGfe/TZErs+yvJ9YJWxl1DQaeE9pc6iycHDz1AC2IZ1iPtqyeJOiH7x NjFZA7RHhI9XDhltcCgeytmrSv9YzMrl/oZFwdeldlJNE+BbjJLCXJDKGrxPT8ZhXgMv 60kBvH7Hh78+r/5YZ2IGo9MWehMaC2tUoQHDXP1HDPSTz7W3f+V0mh0CS/AxCB24d2yy +Rui2O9WU90p9pcXfAMKsf3REYZbQzIi6CQoeIMZI4XCur95bWxA5UCwM50JDhy46l8U JTnQ== X-Gm-Message-State: ALoCoQmvhCxuJnc021mP3gHCeV9caV3pzu/ENhTKb5Gfmxzu9gobYjlFKL1u7sxPTnUYXyacX5My X-Received: by 10.68.219.3 with SMTP id pk3mr33820390pbc.85.1448251652961; Sun, 22 Nov 2015 20:07:32 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id v80sm7812079pfa.92.2015.11.22.20.07.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Nov 2015 20:07:32 -0800 (PST) Date: Sun, 22 Nov 2015 20:07:43 -0800 From: Stephen Hemminger To: "Xie, Huawei" Message-ID: <20151122200743.34511547@xeon-e3> In-Reply-To: References: <1447817231-10510-1-git-send-email-zhihong.wang@intel.com> <1447817231-10510-3-git-send-email-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE094183467C@SHSMSX152.ccr.corp.intel.com> <564D930C.7060108@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 04:07:34 -0000 On Mon, 23 Nov 2015 03:46:31 +0000 "Xie, Huawei" wrote: > > > > Why cannot we rely on the kernel zeroing the memory ? > > If that behavior were to change, then we can zero out the memory > > ourselves. > It is undocumented kernel behavior. My opinion is if not a big burden, > zero out the needed memory ourselves, otherwise resort to this kernel > behavior. Really, I think it is more an oversight of missing documentation, the kernel has always (and will continue) to zero out memory that is given to a process. If it didn't it would be a massive security hole.