On Fri, Jun 26, 2020 at 01:32:15PM +0200, Peter Zijlstra wrote:
> That is, this is boot time only, right? clone() would return -ENOMEM, as
> it's part of the normal page-table copy.
Yes, the pre-allocation happens shortly after the buddy allocator took
over from bootmem. I don't quite get what clo
On Fri, Jun 26, 2020 at 01:31:01PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 26, 2020 at 01:17:11PM +0200, Joerg Roedel wrote:
> > On Fri, Jun 26, 2020 at 01:07:31PM +0200, Peter Zijlstra wrote:
> > > Can't we now remove arch_sync_kernel_mappings() from this same file?
> >
> > Only if we panic on
On Fri, Jun 26, 2020 at 01:17:11PM +0200, Joerg Roedel wrote:
> On Fri, Jun 26, 2020 at 01:07:31PM +0200, Peter Zijlstra wrote:
> > Can't we now remove arch_sync_kernel_mappings() from this same file?
>
> Only if we panic on allocation failure.
I think we do that in plenty places already, so sure
On Fri, Jun 26, 2020 at 01:07:31PM +0200, Peter Zijlstra wrote:
> Can't we now remove arch_sync_kernel_mappings() from this same file?
Only if we panic on allocation failure.
Joerg
On Fri, Jun 26, 2020 at 11:34:50AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Pre-allocate the page-table pages for the vmalloc area at the level
> which needs synchronization on x86. This is P4D for 5-level and PUD
> for 4-level paging.
>
> Doing this at boot makes sure all page-tables
From: Joerg Roedel
Pre-allocate the page-table pages for the vmalloc area at the level
which needs synchronization on x86. This is P4D for 5-level and PUD
for 4-level paging.
Doing this at boot makes sure all page-tables in the system have these
pages already and do not need to be synchronized a
6 matches
Mail list logo