[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200508191048.GA2957@hirez.programming.kicks-ass.net>
Date: Fri, 8 May 2020 21:10:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Joerg Roedel <joro@...tes.org>
Cc: x86@...nel.org, hpa@...or.com,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, rjw@...ysocki.net,
Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...nel.org>,
Joerg Roedel <jroedel@...e.de>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-arch@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [RFC PATCH 2/7] mm/vmalloc: Track which page-table levels were
modified
On Fri, May 08, 2020 at 04:40:38PM +0200, Joerg Roedel wrote:
> +/*
> + * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values
> + * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings()
> + * needs to be called.
> + */
> +#ifndef ARCH_PAGE_TABLE_SYNC_MASK
> +#define ARCH_PAGE_TABLE_SYNC_MASK 0
> +#endif
> +
> +void arch_sync_kernel_mappings(unsigned long start, unsigned long end);
> + if (mask & ARCH_PAGE_TABLE_SYNC_MASK)
> + arch_sync_kernel_mappings(start, end);
So you're relying on the compiler DCE'ing the call in the 'normal' case.
Works I suppose, but I went over the patches twice to look for a default
implementation of it before I figured that out ...
Powered by blists - more mailing lists