From: Borislav Petkov <bp@alien8.de>
To: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Cc: rjw@rjwysocki.net, lenb@kernel.org, tony.luck@intel.com,
bp@suse.de, m.chehab@samsung.com, linux-edac@vger.kernel.org,
x86@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org
Subject: Re: [PATCH 6/7] acpi, apei, ghes: Make unmapping functionality independent from architecture.
Date: Tue, 13 May 2014 22:11:18 +0200 [thread overview]
Message-ID: <20140513201118.GF8760@pd.tnic> (raw)
In-Reply-To: <1397056476-9183-7-git-send-email-tomasz.nowicki@linaro.org>
On Wed, Apr 09, 2014 at 05:14:34PM +0200, Tomasz Nowicki wrote:
> Till now __flush_tlb_one was used for unmapping virtual memory which
> is x86 specific function. Replace it with more generic
> flush_tlb_kernel_range.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
> drivers/acpi/apei/ghes.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index aaf8db3..624878b 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -185,7 +185,7 @@ static void ghes_iounmap_nmi(void __iomem *vaddr_ptr)
>
> BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_NMI_PAGE(base));
> unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
> - __flush_tlb_one(vaddr);
> + flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);
> }
>
> static void ghes_iounmap_irq(void __iomem *vaddr_ptr)
> @@ -195,7 +195,7 @@ static void ghes_iounmap_irq(void __iomem *vaddr_ptr)
>
> BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_IRQ_PAGE(base));
> unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
> - __flush_tlb_one(vaddr);
> + flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);
flush_tlb_kernel_range() does send an IPI to every core on x86 which is
much more expensive than what __flush_tlb_one does.
Fairer it would be if you added a __flush_tlb_one() version for arm
which does flush_tlb_kernel_range for you.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-05-13 20:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 15:14 [PATCH 0/7] APEI: Make APEI architecture independent Tomasz Nowicki
2014-04-09 15:14 ` [PATCH 1/7] apei, mce: Call MCE-specific code only for X86 architecture Tomasz Nowicki
2014-05-05 11:44 ` Borislav Petkov
2014-05-05 14:34 ` Tomasz Nowicki
2014-05-05 14:53 ` Borislav Petkov
2014-05-05 15:32 ` Tomasz Nowicki
2014-05-05 15:33 ` Borislav Petkov
2014-05-05 15:36 ` Tomasz Nowicki
2014-04-09 15:14 ` [PATCH 2/7] acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications Tomasz Nowicki
2014-05-13 18:13 ` Borislav Petkov
2014-05-15 14:31 ` Tomasz Nowicki
2014-05-21 18:11 ` Borislav Petkov
2014-04-09 15:14 ` [PATCH 3/7] ACPI, APEI, GHES: Introduce ACPI_APEI_NMI to make NMI error notification a GHES feature Tomasz Nowicki
2014-04-09 15:14 ` [PATCH 4/7] acpi, apei, ghes: Factor out NMI error notification context Tomasz Nowicki
2014-05-13 19:41 ` Borislav Petkov
2014-05-23 12:06 ` Tomasz Nowicki
2014-05-23 16:48 ` Borislav Petkov
2014-05-26 13:26 ` Tomasz Nowicki
2014-05-26 13:45 ` Borislav Petkov
2014-05-26 14:02 ` Tomasz Nowicki
2014-04-09 15:14 ` [PATCH 5/7] acpi, apei, ghes: Attach NMI init/deinit functions while CONFIG_ACPI_APEI_NMI is enabled Tomasz Nowicki
2014-05-13 19:49 ` Borislav Petkov
2014-04-09 15:14 ` [PATCH 6/7] acpi, apei, ghes: Make unmapping functionality independent from architecture Tomasz Nowicki
2014-05-13 20:11 ` Borislav Petkov [this message]
2014-05-14 12:32 ` Tomasz Nowicki
2014-05-14 12:35 ` Will Deacon
2014-05-14 12:45 ` Catalin Marinas
2014-05-14 12:48 ` Will Deacon
2014-05-14 12:52 ` Tomasz Nowicki
2014-05-14 13:21 ` Borislav Petkov
2014-04-09 15:14 ` [PATCH 7/7] acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context Tomasz Nowicki
2014-05-14 17:13 ` Borislav Petkov
2014-05-05 9:25 ` [PATCH 0/7] APEI: Make APEI architecture independent Tomasz Nowicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140513201118.GF8760@pd.tnic \
--to=bp@alien8.de \
--cc=bp@suse.de \
--cc=lenb@kernel.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=tomasz.nowicki@linaro.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.