Hi Dan,
On Thu, 4 Apr 2019 at 21:21, Dan Williams wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a special
> purpose".
>
> The proposed Linux behavior for special purpose memory is that it is
> reserved for
On Wed, Apr 03, 2019 at 09:20:39AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote:
> > - On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote:
> >
> > > On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote:
> > >>
From: Alexander Duyck
Introduce a new iterator for_each_free_mem_pfn_range_in_zone.
This iterator will take care of making sure a given memory range provided
is in fact contained within a zone. It takes are of all the bounds checking
we were doing in deferred_grow_zone, and
From: Alexander Duyck
Use the same approach that was already in use on Sparc on all the
architectures that support a 64b long.
This is mostly motivated by the fact that 7 to 10 store/move instructions
are likely always going to be faster than having to call into a function
that is not
This patchset is essentially a refactor of the page initialization logic
that is meant to provide for better code reuse while providing a
significant improvement in deferred page initialization performance.
In my testing on an x86_64 system with 384GB of RAM I have seen the
following. In the case
From: Alexander Duyck
As best as I can tell the meminit_pfn_in_nid call is completely redundant.
The deferred memory initialization is already making use of
for_each_free_mem_range which in turn will call into __next_mem_range which
will only return a memory range if it matches the node ID
From: Alexander Duyck
Add yet another iterator, for_each_free_mem_range_in_zone_from, and then
use it to support initializing and freeing pages in groups no larger than
MAX_ORDER_NR_PAGES. By doing this we can greatly improve the cache locality
of the pages while we do several loops over them in
On Fri, 5 Apr 2019 09:56:22 -0700
Dan Williams wrote:
> On Fri, Apr 5, 2019 at 9:24 AM Jonathan Cameron
> wrote:
> >
> > On Fri, 5 Apr 2019 08:43:03 -0700
> > Dan Williams wrote:
> >
> > > On Fri, Apr 5, 2019 at 4:19 AM Jonathan Cameron
> > > wrote:
> > > >
> > > > On Thu, 4 Apr 2019
On Fri, Apr 5, 2019 at 9:24 AM Jonathan Cameron
wrote:
>
> On Fri, 5 Apr 2019 08:43:03 -0700
> Dan Williams wrote:
>
> > On Fri, Apr 5, 2019 at 4:19 AM Jonathan Cameron
> > wrote:
> > >
> > > On Thu, 4 Apr 2019 12:08:49 -0700
> > > Dan Williams wrote:
> > >
> > > > Memory that has been tagged
On Fri, 5 Apr 2019 08:43:03 -0700
Dan Williams wrote:
> On Fri, Apr 5, 2019 at 4:19 AM Jonathan Cameron
> wrote:
> >
> > On Thu, 4 Apr 2019 12:08:49 -0700
> > Dan Williams wrote:
> >
> > > Memory that has been tagged EFI_SPECIAL_PURPOSE, and has performance
> > > properties described by the
Li RongQing writes:
> If offset is not zero and length is bigger than PAGE_SIZE,
> this will cause to out of boundary access to a page memory
Agreed, though I don't think this can be triggered in practice.
> Fixes: 98cc093cba1e "(block, THP: make block_device_operations.rw_page
> support
On Fri, Apr 5, 2019 at 4:19 AM Jonathan Cameron
wrote:
>
> On Thu, 4 Apr 2019 12:08:49 -0700
> Dan Williams wrote:
>
> > Memory that has been tagged EFI_SPECIAL_PURPOSE, and has performance
> > properties described by the ACPI HMAT is expected to have an application
> > specific consumer.
> >
>
On Thu, 4 Apr 2019 12:08:49 -0700
Dan Williams wrote:
> Memory that has been tagged EFI_SPECIAL_PURPOSE, and has performance
> properties described by the ACPI HMAT is expected to have an application
> specific consumer.
>
> Those consumers may want 100% of the memory capacity to be reserved
13 matches
Mail list logo
