From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most "generic" version of pfn_va
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn
On Wed, Apr 21, 2021 at 10:37:11AM +, peter.enderb...@sony.com wrote:
> On 4/21/21 11:15 AM, Daniel Vetter wrote:
> >
> > We need to understand what the "correct" value is. Not in terms of kernel
> > code, but in terms of semantics. Like if userspace allocates a GL texture,
> > is this
On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Par
On Wed, Apr 21, 2021 at 04:29:48PM +0530, Anshuman Khandual wrote:
>
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothin
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.
Introduce
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most "generic" version of pfn_va
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn
On Tue, Apr 20, 2021 at 06:00:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Parts
On Tue, Apr 20, 2021 at 05:57:57PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing e
On Tue, Apr 20, 2021 at 05:18:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 17:03, Mike Rapoport wrote:
> > On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> > > On 20.04.21 11:09, Mike Rapoport wrote:
> > > > From: Mike Rapoport
>
On Tue, Apr 20, 2021 at 05:18:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 17:03, Mike Rapoport wrote:
> > On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> > > On 20.04.21 11:09, Mike Rapoport wrote:
> > > > From: Mike Rapoport
>
From: Mike Rapoport
Hi,
This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.
@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.
v3:
* add missing put_compound_head() if we are to return NULL
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 8 +---
1 file changed, 5
On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 8 +---
1 file changed, 5
From: Mike Rapoport
Hi,
This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.
@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.
v3:
* add missing put_compound_head() if we are to return NULL
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
On Tue, Apr 20, 2021 at 02:24:30PM +0100, Matthew Wilcox wrote:
> On Tue, Apr 20, 2021 at 03:13:54PM +0300, Mike Rapoport wrote:
> > Add a paragraph that explains that it may happen that the counters in
> > /proc/meminfo do not add up to the overall memory usage.
>
> ...
It seems I've messed this posting entirely :(
Please ignore it, sorry for the noise.
On Tue, Apr 20, 2021 at 04:16:07PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an updated version of page_is_secretmem() changes.
> This is based on v5.12-rc7-mmot
It seems I've messed this posting entirely :(
Please ignore it, sorry for the noise.
On Tue, Apr 20, 2021 at 04:16:07PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an updated version of page_is_secretmem() changes.
> This is based on v5.12-rc7-mmot
On Tue, Apr 20, 2021 at 03:19:56PM +0200, David Hildenbrand wrote:
> On 20.04.21 15:16, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The check in gup_pte_range() whether a page belongs to a secretmem mapping
> > is performed before grabbing the page reference.
On Tue, Apr 20, 2021 at 03:19:56PM +0200, David Hildenbrand wrote:
> On 20.04.21 15:16, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The check in gup_pte_range() whether a page belongs to a secretmem mapping
> > is performed before grabbing the page reference.
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 6 +++---
1 file changed, 3
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 6 +++---
1 file changed, 3
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 6 +++---
1 file changed, 3
From: Mike Rapoport
The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.
To avoid potential race move the check after try_grab_compound_head().
Signed-off-by: Mike Rapoport
---
mm/gup.c | 6 +++---
1 file changed, 3
From: Mike Rapoport
Hi,
This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.
@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.
v2:
* move the check for secretmem page in gup_pte_range after
From: Mike Rapoport
Hi,
This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.
@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.
v2:
* move the check for secretmem page in gup_pte_range after
On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Add comment describing the semantics of pfn_valid() that clarifies that
> > pfn_valid() only checks for availability of a me
On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Add comment describing the semantics of pfn_valid() that clarifies that
> > pfn_valid() only checks for availability of a me
On Tue, Apr 20, 2021 at 03:13:54PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Add a paragraph that explains that it may happen that the counters in
> /proc/meminfo do not add up to the overall memory usage.
>
> Signed-off-by: Mike Rapoport
Ooops, forgot to add M
From: Mike Rapoport
Add a paragraph that explains that it may happen that the counters in
/proc/meminfo do not add up to the overall memory usage.
Signed-off-by: Mike Rapoport
---
v2:
* Add brief changelog
* Fix typo
* Update example about network memory usage according to Eric's comment
On Tue, Apr 20, 2021 at 11:10:03AM +0200, Michal Hocko wrote:
> On Tue 20-04-21 11:51:05, Mike Rapoport wrote:
> > From: Mike Rapoport
>
> Some trivial changelog would be better than nothing.
oh, sure.
> > Signed-off-by: Mike Rapoport
>
> But I do agree that t
On Tue, Apr 20, 2021 at 10:45:21AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 11:41 AM, Mike Rapoport wrote:
> > Hello Peter,
> >
> > On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> >> On 4/20/21 10:58 AM, Daniel Vetter wrote:
&g
On Tue, Apr 20, 2021 at 10:45:21AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 11:41 AM, Mike Rapoport wrote:
> > Hello Peter,
> >
> > On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> >> On 4/20/21 10:58 AM, Daniel Vetter wrote:
&g
Hello Peter,
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is
Hello Peter,
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.
Introduce
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.
Introduce
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most "generic" version of pfn_va
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most "generic" version of pfn_va
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn
From: Mike Rapoport
Signed-off-by: Mike Rapoport
---
Documentation/filesystems/proc.rst | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/proc.rst
b/Documentation/filesystems/proc.rst
index 48fbfc336ebf..bf245151645b 100644
On Tue, Apr 20, 2021 at 09:04:51AM +0200, Michal Hocko wrote:
> On Mon 19-04-21 18:37:13, Christian König wrote:
> > Am 19.04.21 um 18:11 schrieb Michal Hocko:
> [...]
> > > The question is not whether it is NUMA aware but whether it is useful to
> > > know per-numa data for the purpose the
On Tue, Apr 20, 2021 at 09:04:51AM +0200, Michal Hocko wrote:
> On Mon 19-04-21 18:37:13, Christian König wrote:
> > Am 19.04.21 um 18:11 schrieb Michal Hocko:
> [...]
> > > The question is not whether it is NUMA aware but whether it is useful to
> > > know per-numa data for the purpose the
On Mon, Apr 19, 2021 at 01:21:56PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 02:56:17PM +0300, Mike Rapoport wrote:
>
> > > With that fixed, you'll have a head page that you can use for testing,
> > > which means you don't need to test PageCompound() (because
On Mon, Apr 19, 2021 at 01:21:56PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 02:56:17PM +0300, Mike Rapoport wrote:
>
> > > With that fixed, you'll have a head page that you can use for testing,
> > > which means you don't need to test PageCompound() (because
On Mon, Apr 19, 2021 at 12:23:02PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 11:42:18AM +0300, Mike Rapoport wrote:
> > The perf profile of the test indicated that the regression is caused by
> > page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_r
On Mon, Apr 19, 2021 at 12:23:02PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 11:42:18AM +0300, Mike Rapoport wrote:
> > The perf profile of the test indicated that the regression is caused by
> > page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_r
On Mon, Apr 19, 2021 at 11:40:56AM +0200, David Hildenbrand wrote:
> On 19.04.21 11:38, David Hildenbrand wrote:
> > On 19.04.21 11:36, Mike Rapoport wrote:
> > > On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> > > > On 19.04.21 10:42, Mike Rapopo
On Mon, Apr 19, 2021 at 11:40:56AM +0200, David Hildenbrand wrote:
> On 19.04.21 11:38, David Hildenbrand wrote:
> > On 19.04.21 11:36, Mike Rapoport wrote:
> > > On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> > > > On 19.04.21 10:42, Mike Rapopo
On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> On 19.04.21 10:42, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
> > due to commit "mm: introduce memfd_secr
On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> On 19.04.21 10:42, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
> > due to commit "mm: introduce memfd_secr
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".
The perf profile of the test indicated that the regression is caused by
page_is_sec
From: Mike Rapoport
CAVIUM_OCTEON_SOC configuration selects HOLES_IN_ZONE option to cope with
memory crashes that were happening in 2011.
This option effectively aliases pfn_valid_within() to pfn_valid() when
enabled and hardwires it to 1 when disabled. The check for
pfn_valid_within() is only
On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote:
> > Not sure we really need a new pagetype here, PG_Reserved seems to be quite
> > enough to say "don't touch this". I generally agree that we could make
> > PG_Reserved a PageType and then have several sub-types for reserved
On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote:
> > Not sure we really need a new pagetype here, PG_Reserved seems to be quite
> > enough to say "don't touch this". I generally agree that we could make
> > PG_Reserved a PageType and then have several sub-types for reserved
On Thu, Apr 15, 2021 at 11:31:26AM +0200, David Hildenbrand wrote:
> On 14.04.21 22:29, Mike Rapoport wrote:
> > On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> > > On 08.04.21 07:14, Anshuman Khandual wrote:
> > > >
> > > &g
On Thu, Apr 15, 2021 at 11:31:26AM +0200, David Hildenbrand wrote:
> On 14.04.21 22:29, Mike Rapoport wrote:
> > On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> > > On 08.04.21 07:14, Anshuman Khandual wrote:
> > > >
> > > &g
On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> On 08.04.21 07:14, Anshuman Khandual wrote:
> >
> > On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The intended semantics of pfn_valid() is to v
On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> On 08.04.21 07:14, Anshuman Khandual wrote:
> >
> > On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The intended semantics of pfn_valid() is to v
On Wed, Apr 14, 2021 at 05:52:57PM +0200, David Hildenbrand wrote:
> On 14.04.21 17:27, Ard Biesheuvel wrote:
> > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
> > >
> > > On 07.04.21 19:26, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> &g
On Wed, Apr 14, 2021 at 05:52:57PM +0200, David Hildenbrand wrote:
> On 14.04.21 17:27, Ard Biesheuvel wrote:
> > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
> > >
> > > On 07.04.21 19:26, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> &g
On Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
> >
> > On 07.04.21 19:26, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The struct pages representing a reserved
On Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
> >
> > On 07.04.21 19:26, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The struct pages representing a reserved
On Wed, Apr 14, 2021 at 05:12:11PM +0200, David Hildenbrand wrote:
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This
On Wed, Apr 14, 2021 at 05:12:11PM +0200, David Hildenbrand wrote:
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This
On Mon, Apr 12, 2021 at 11:45:45PM -0700, Ilya Lipnitskiy wrote:
> Hi Thomas,
>
> On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer
> wrote:
> >
> > On Sat, Apr 03, 2021 at 07:02:13PM -0700, Ilya Lipnitskiy wrote:
> > > Hi Mike,
> > >
> > > On
On Wed, Apr 14, 2021 at 10:46:05AM +0200, Christian Brauner wrote:
> On Wed, Apr 14, 2021 at 08:14:22AM +0200, Mauro Carvalho Chehab wrote:
> > Em Tue, 13 Apr 2021 21:40:20 -0700
> > Yury Norov escreveu:
> >
> > > Ping?
> > >
> > > On Fri, Apr 09, 2021 at 01:43:04PM -0700, Yury Norov wrote:
> >
On Wed, Apr 14, 2021 at 09:42:01AM +0200, David Hildenbrand wrote:
> On 13.04.21 19:53, Rafael J. Wysocki wrote:
> > On Tue, Apr 13, 2021 at 7:43 PM David Hildenbrand wrote:
> > >
> > > On 13.04.21 16:01, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > > >
> > > > Commit
The following commit has been merged into the x86/boot branch of tip:
Commit-ID: c361e5d4d07d63768880e1994c7ed999b3a94cd9
Gitweb:
https://git.kernel.org/tip/c361e5d4d07d63768880e1994c7ed999b3a94cd9
Author:Mike Rapoport
AuthorDate:Tue, 13 Apr 2021 21:08:39 +03:00
Committer
On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
> On 4/13/21 9:58 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> >>> Hi Randy,
> >>>
> >&g
On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> >>> On Mon, Apr
Hi Randy,
On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >
> > I thought about adding some prints to see what's causing the hang, the
> > re
On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> On 4/11/21 11:14 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> >> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> >>>
9
>
>
> I reverted both of these patches and the laptop boots successfully:
>
> commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
> Author: Mike Rapoport
> Date: Tue Mar 2 12:04:05 2021 +0200
>
> x86/setup: Consolidate early memory reservations
>
> &&
On Fri, Apr 09, 2021 at 02:07:24PM +0200, David Hildenbrand wrote:
> On 09.04.21 13:39, Alex Ghiti wrote:
> > Hi David,
>
> I assume you still somehow create the direct mapping for the kernel, right?
> So it's really some memory region with a direct mapping but without a memmap
> (and right now,
On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote:
> > > > Also, will that memory properly be exposed in the resource tree as
> > > > System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/kcore)
> > > > won't work as expected - the kernel won't be included in a dump.
> > Do
On Fri, Apr 09, 2021 at 07:39:59AM -0400, Alex Ghiti wrote:
> Hi David,
>
> Le 4/9/21 à 4:23 AM, David Hildenbrand a écrit :
> > On 09.04.21 09:14, Alex Ghiti wrote:
> > > Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit :
> > > > From: Vitaly Wool
> > > >
> > > > Introduce XIP (eXecute In Place)
CMA"
> instead, such that user configuration and dependencies are respected.
>
> v1 -> v2:
> - Fix DRM_CMA -> DMA_CMA
>
> Cc: Joel Stanley
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Jeffery
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Chri
CMA"
> instead, such that user configuration and dependencies are respected.
>
> v1 -> v2:
> - Fix DRM_CMA -> DMA_CMA
>
> Cc: Joel Stanley
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Jeffery
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Chri
On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower
1201 - 1300 of 6433 matches
Mail list logo
