DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xie, Huawei" <huawei.xie@intel.com>
To: "Wang, Zhihong" <zhihong.wang@intel.com>,
	"Mcnamara, John" <john.mcnamara@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove	unnecessary	hugepage zero-filling
Date: Thu, 19 Nov 2015 06:09:27 +0000	[thread overview]
Message-ID: <C37D651A908B024F974696C65296B57B4B19B689@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <8F6C2BD409508844A0EFC19955BE0941834AFE@SHSMSX152.ccr.corp.intel.com>

On 11/19/2015 11:54 AM, Wang, Zhihong wrote:
>
>> -----Original Message-----
>> From: Xie, Huawei
>> Sent: Wednesday, November 18, 2015 8:08 PM
>> To: Wang, Zhihong <zhihong.wang@intel.com>; Mcnamara, John
>> <john.mcnamara@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
>> hugepage zero-filling
>>
>> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:
>>>> -----Original Message-----
>>>> From: Mcnamara, John
>>>> Sent: Wednesday, November 18, 2015 6:40 PM
>>>> To: Wang, Zhihong <zhihong.wang@intel.com>; dev@dpdk.org
>>>> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
>>>> unnecessary hugepage zero-filling
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhihong Wang
>>>>> Sent: Wednesday, November 18, 2015 3:27 AM
>>>>> To: dev@dpdk.org
>>>>> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
>>>>> unnecessary hugepage zero-filling
>>>>>
>>>>> The kernel fills new allocated (huge) pages with zeros.
>>>>> DPDK just has to touch the pages to trigger the allocation.
>> I think we shouldn't reply on the assumption that kernel has zeroed the memory.
> I understand the concern.
> In my opinion application shouldn't assume malloced memory to be zero-filled. So it should be okay for DPDK even if the kernel doesn't zero the page at all.
For malloc, we shouldn't make this assumption because it might allocate
just freed memory from the heap. Hugetlbfs is different. Let us listen
to other people's opinion.
It will make life much easier if we could make this assumption.
>
> I agree that we should check if any code accidentally make that assumption. Currently there's rte_pktmbuf_init() for packet mbuf initialization.
>
> /Zhihong
>
>
>> Kernel zeroes the memory mostly to avoid information leakage.It could also
>> achieve this by setting each bit to 1.
>> What we indeed need to check is later DPDK initialization code doesn't assume
>> the memory has been zeroed. Otherwise zero only that part of the memory.
>> Does this makes sense?
>>
>>>>> ...
>>>>>  		if (orig) {
>>>>>  			hugepg_tbl[i].orig_va = virtaddr;
>>>>> -			memset(virtaddr, 0, hugepage_sz);
>>>>> +			memset(virtaddr, 0, 8);
>>>>>  		}
>>>> Probably worth adding a one or two line comment here to avoid someone
>>>> thinking that it is a bug at some later stage. The text in the commit
>>>> message above is suitable.
>>>>
>>> Good suggestion! Will add it :)
>>>
>>>> John.
>>>> --
>


  reply	other threads:[~2015-11-19  6:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18  3:27 [dpdk-dev] [RFC PATCH 0/2] Reduce DPDK initialization time Zhihong Wang
2015-11-18  3:27 ` [dpdk-dev] [RFC PATCH 1/2] lib/librte_eal: Reduce timer " Zhihong Wang
2015-11-18  3:27 ` [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Zhihong Wang
2015-11-18 10:39   ` Mcnamara, John
2015-11-18 10:44     ` Wang, Zhihong
2015-11-18 12:07       ` Xie, Huawei
2015-11-18 16:00         ` Stephen Hemminger
2015-11-18 16:13           ` Richardson, Bruce
2015-11-18 19:09             ` Stephen Hemminger
2015-11-19  2:15               ` Wang, Zhihong
2015-11-19  6:04                 ` Xie, Huawei
2015-11-19  6:32                   ` Wang, Zhihong
2015-11-19  9:18                     ` Sergio Gonzalez Monroy
2015-11-23  2:54                     ` Xie, Huawei
2015-11-23 10:18                       ` Bruce Richardson
2015-11-20 12:15               ` Bruce Richardson
2015-11-19  3:54         ` Wang, Zhihong
2015-11-19  6:09           ` Xie, Huawei [this message]
2015-11-19  9:14         ` Sergio Gonzalez Monroy
2015-11-23  3:46           ` Xie, Huawei
2015-11-23  4:07             ` Stephen Hemminger
2015-11-23  5:05               ` Xie, Huawei
2015-11-23  6:52                 ` Stephen Hemminger
2015-11-25 18:24                   ` Xie, Huawei
2015-12-24  8:34 ` [dpdk-dev] [RFC PATCH 0/2] Reduce DPDK initialization time Qiu, Michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C37D651A908B024F974696C65296B57B4B19B689@SHSMSX101.ccr.corp.intel.com \
    --to=huawei.xie@intel.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).