From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by dpdk.org (Postfix) with ESMTP id B6D748E80 for ; Mon, 23 Nov 2015 07:52:11 +0100 (CET) Received: by pabfh17 with SMTP id fh17so187498617pab.0 for ; Sun, 22 Nov 2015 22:52:11 -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=DTuYLXcyQF8vKTwuY1nhGTO2+Rtl2DDoucjg3/LOoV0=; b=SLA6lF5G1UyWUE2M0pS6q6h2oVR1RFzk7rJ0qR8FKEX4cZW0bp1tUXHPDLF4DNv2FG 1+SmoMLZLIuysvdpWb54RFvWsZSzKk0ujoL8KZCTvDV2hUQJpUUyfa0kQ4FSkubc/J8g ug1ZnVug2XjBo0cjhczJ1mM6V3Sn+FlhFU1v/S+4hBcJxtlXKVszkE/kADATiislABZj KJ/ZnaoiDK7V57jfHjOU1lmuOzEbu7Po2fSO+/PXCA0PK+InzYj1OBBzwStKCoT5DWja W5dI/HV1ybUEFHNg8Uhp13HuymvVPnTe5BNo8qRql7lCUuYAdYDsxjkheqBOO+QnH45l EKxw== 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=DTuYLXcyQF8vKTwuY1nhGTO2+Rtl2DDoucjg3/LOoV0=; b=mJ+rC2j5AY39BkhDanfPQsDdgDZ5ZTi2BRxYB9TibeRiL2vUO6J2zc3rFZNtHY/LY3 pnQMUXO2rDbEoTtSPihCsbA92YIyzTbnGVIfm+S10E9vYwr18Bhyt6c99o9S1BJ+n7ut Sj2K6DTaJYTfKLSu+54To5R6Q8OT6uA8GqB/a5US/6YNVYbtev/ts/CUqzIoVXTWQ+qp dHjpHb1Tr1Gja1NA0SdD3+sPF0KE39kvK1a0jupinDH9BC5MHKol7C0dmjg/nMnlQgXe BVzG7L/b+0EPajFcFN3EAkWJlhFKNfYQ878VIKN9uYWcaT2FW6uGxsOxia7iDExx8xCx u9UA== X-Gm-Message-State: ALoCoQn/svaK8ilXs/6cH8uL0bh2k0K9jRGwhD7CAXg6pk6fJbQY5hkN4/yvddMvs5V3A/fU3j0K X-Received: by 10.98.75.71 with SMTP id y68mr14211195pfa.75.1448261530922; Sun, 22 Nov 2015 22:52:10 -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 rn7sm8964195pab.23.2015.11.22.22.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Nov 2015 22:52:10 -0800 (PST) Date: Sun, 22 Nov 2015 22:52:20 -0800 From: Stephen Hemminger To: "Xie, Huawei" Message-ID: <20151122225220.1fd15ba8@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> <20151122200743.34511547@xeon-e3> 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 06:52:12 -0000 On Mon, 23 Nov 2015 05:05:21 +0000 "Xie, Huawei" wrote: > On 11/23/2015 12:07 PM, Stephen Hemminger wrote: > > 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. > Agree. I believe this behavior will not change in future. For the > security issue, kernel could also set all bits like to 1. Just wonder if > this is best practice and whether there are other user space programs > rely on this behavior. > Glibc almost certainly depends on this, because heap is grown by mmaping addtional memory.