On 16-Nov-18 2:42 PM, Alejandro Lucero wrote:
On Fri, Nov 16, 2018 at 1:35 PM Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 16-Nov-18 12:49 PM, Alejandro Lucero wrote:
>
>
> On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
> mailto:anatoly.bura...@inte
On Fri, Nov 16, 2018 at 1:35 PM Burakov, Anatoly
wrote:
> On 16-Nov-18 12:49 PM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 12-Nov-18 11:18 AM, Alejandro Lucero wrote:
> > > When using larg
On 16-Nov-18 12:49 PM, Alejandro Lucero wrote:
On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 12-Nov-18 11:18 AM, Alejandro Lucero wrote:
> When using large amount of hugepage based memory, doing all the
> hugepages mapping can tak
On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
wrote:
> On 12-Nov-18 11:18 AM, Alejandro Lucero wrote:
> > When using large amount of hugepage based memory, doing all the
> > hugepages mapping can take quite significant time.
> >
> > The problem is hugepages being initially mmaped to virtual ad
On 12-Nov-18 11:18 AM, Alejandro Lucero wrote:
When using large amount of hugepage based memory, doing all the
hugepages mapping can take quite significant time.
The problem is hugepages being initially mmaped to virtual addresses
which will be tried later for the final hugepage mmaping. This ca
When using large amount of hugepage based memory, doing all the
hugepages mapping can take quite significant time.
The problem is hugepages being initially mmaped to virtual addresses
which will be tried later for the final hugepage mmaping. This causes
the final mapping requiring calling mmap wit
6 matches
Mail list logo