[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX6eF69da2qchpS=G=P25QLgGsZXYTo=QcTocSxdbLH9A@mail.gmail.com>
Date: Fri, 19 Jun 2015 09:14:14 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...e.de>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
John Stultz <john.stultz@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Len Brown <lenb@...nel.org>, Huang Rui <ray.huang@....com>,
Denys Vlasenko <dvlasenk@...hat.com>,
kvm list <kvm@...r.kernel.org>,
Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH v3 03/18] x86/tsc/paravirt: Remove the read_tsc and
read_tscp paravirt hooks
On Fri, Jun 19, 2015 at 8:32 AM, Borislav Petkov <bp@...e.de> wrote:
> On Tue, Jun 16, 2015 at 05:35:51PM -0700, Andy Lutomirski wrote:
>> We've had read_tsc and read_tscp paravirt hooks since the very
>> beginning of paravirt, i.e., d3561b7fa0fb ("[PATCH] paravirt: header
>> and stubs for paravirtualisation"). AFAICT the only paravirt guest
>> implementation that ever replaced these calls was vmware, and it's
>> gone. Arguably even vmware shouldn't have hooked rdtsc -- we fully
>> support systems that don't have a TSC at all, so there's no point
>> for a paravirt implementation to pretend that we have a TSC but to
>> replace it.
>>
>> I also doubt that these hooks actually worked. Calls to rdtscl and
>> rdtscll, which respected the hooks, were used seemingly
>> interchangeably with native_read_tsc, which did not.
>>
>> Just remove them. If anyone ever needs them again, they can try
>> to make a case for why they need them.
>>
>> Before, on a paravirt config:
>> text data bss dec hex filename
>> 13426505 1827056 14508032 29761593 1c62039 vmlinux
>>
>> After:
>> text data bss dec hex filename
>> 13426617 1827056 14508032 29761705 1c620a9 vmlinux
>
> Those look swapped. I mean, you're removing a bunch of stuff and text
> grew?!
Trying again. The config is different, so the numbers won't match.
Before:
text data bss dec hex filename
12618257 1816384 1093632 15528273 ecf151 vmlinux
After:
text data bss dec hex filename
12617207 1816384 1093632 15527223 eced37 vmlinux
So, yes, I have it backwards. There's some penalty here because this
patch also causes rdtsc to be inlined on paravirt kernels (it was
patched as a call instead of an inline instruction sequence), so each
call site pays for the shift, the or, and the pointless zero
extension.
With the "unsigned long" patch, it's:
text data bss dec hex filename
12617002 1816384 1093632 15527018 ecec6a vmlinux
Want to fix up the commit message? It seems silly to re-send the
whole series for this.
--Andy
>
>> Signed-off-by: Andy Lutomirski <luto@...nel.org>
>> ---
>> arch/x86/include/asm/msr.h | 16 ++++++++--------
>> arch/x86/include/asm/paravirt.h | 34 ----------------------------------
>> arch/x86/include/asm/paravirt_types.h | 2 --
>> arch/x86/kernel/paravirt.c | 2 --
>> arch/x86/kernel/paravirt_patch_32.c | 2 --
>> arch/x86/xen/enlighten.c | 3 ---
>> 6 files changed, 8 insertions(+), 51 deletions(-)
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists