linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	andi@firstfloor.org, linux-kernel@vger.kernel.org,
	x86@kernel.org
Subject: Re: [PATCH] x86: Improve 64 bit __phys_addr call performance
Date: Wed, 24 Oct 2012 09:31:05 -0700	[thread overview]
Message-ID: <508817C9.2080604@intel.com> (raw)
In-Reply-To: <20121024102533.GA10447@gmail.com>

On 10/24/2012 03:25 AM, Ingo Molnar wrote:
> * Alexander Duyck <alexander.h.duyck@intel.com> wrote:
>
>> This patch is meant to improve overall system performance when 
>> making use of the __phys_addr call on 64 bit x86 systems.  To 
>> do this I have implemented several changes.
>>
>> First if CONFIG_DEBUG_VIRTUAL is not defined __phys_addr is 
>> made an inline, similar to how this is currently handled in 32 
>> bit.  However in order to do this it is required to export 
>> phys_base so that it is available if __phys_addr is used in 
>> kernel modules.
>>
>> The second change was to streamline the code by making use of 
>> the carry flag on an add operation instead of performing a 
>> compare on a 64 bit value.  The advantage to this is that it 
>> allows us to reduce the overall size of the call. On my Xeon 
>> E5 system the entire __phys_addr inline call consumes 30 bytes 
>> and 5 instructions.  I also applied similar logic to the debug 
>> version of the function.  My testing shows that the debug 
>> version of the function with this patch applied is slightly 
>> faster than the non-debug version without the patch.
>>
>> Finally, when building the kernel with the first two changes 
>> applied I saw build warnings about __START_KERNEL_map and 
>> PAGE_OFFSET constants not fitting in their type.  In order to 
>> resolve the build warning I changed their type from UL to ULL.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>>
>>  arch/x86/include/asm/page_64_types.h |   16 ++++++++++++++--
>>  arch/x86/kernel/x8664_ksyms_64.c     |    3 +++
>>  arch/x86/mm/physaddr.c               |   20 ++++++++++++++------
>>  3 files changed, 31 insertions(+), 8 deletions(-)
>> +#ifdef CONFIG_DEBUG_VIRTUAL
>>  extern unsigned long __phys_addr(unsigned long);
>> +#else
>> +static inline unsigned long __phys_addr(unsigned long x)
>> +{
>> +	unsigned long y = x - __START_KERNEL_map;
>> +
>> +	/* use the carry flag to determine if x was < __START_KERNEL_map */
>> +	x = y + ((x > y) ? phys_base : (__START_KERNEL_map - PAGE_OFFSET));
>> +
>> +	return x;
>> +}
> This is a rather frequently used primitive. By how much does 
> this patch increase a 'make defconfig' kernel's vmlinux, as 
> measured via 'size vmlinux'?
>
> Thanks,
>
> 	Ingo

Here is the before and after:

Before
    text    data     bss      dec    hex filename
10368528 1047480 1122304 12538312 bf51c8 vmlinux

After
    text    data     bss      dec    hex filename
10372216 1047480 1122304 12542000 bf6030 vmlinux

I also have some patches are going into the swiotlb.  With them in it
reduces the size a bit but still doesn't get us back to the original size:

After SWIOTLB
    text    data     bss      dec    hex filename
10371860 1047480 1122304 12541644 bf5ecc vmlinux

The total increase in size amounts to about 3.6K without the SWIOTLB
changes, and about 3.3K with.

Thanks,

Alex

      reply	other threads:[~2012-10-24 16:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09 18:50 [PATCH] x86: Improve 64 bit __phys_addr call performance Alexander Duyck
2012-10-10 13:58 ` Andi Kleen
2012-10-10 23:56   ` Alexander Duyck
2012-10-24 10:25 ` Ingo Molnar
2012-10-24 16:31   ` Alexander Duyck [this message]

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=508817C9.2080604@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).