> -----Original Message-----
> From: Xie, Huawei
> Sent: Wednesday, November 18, 2015 8:08 PM
> To: Wang, Zhihong <zhihong.wang at intel.com>; Mcnamara, John
> <john.mcnamara at intel.com>; dev at 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 at intel.com>; dev at 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 at dpdk.org] On Behalf Of Zhihong Wang
> >>> Sent: Wednesday, November 18, 2015 3:27 AM
> >>> To: dev at 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.
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.
> >> --
> >
