From: Alexander Duyck <alexander.h.duyck@intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
andi@firstfloor.org, linux-kernel@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH v3 1/8] x86: Improve __phys_addr performance by making use of carry flags and inlining
Date: Mon, 05 Nov 2012 13:56:28 -0800 [thread overview]
Message-ID: <5098360C.6090805@intel.com> (raw)
In-Reply-To: <20121105202425.GA25671@shutemov.name>
On 11/05/2012 12:24 PM, Kirill A. Shutemov wrote:
> On Mon, Nov 05, 2012 at 11:04:06AM -0800, Alexander Duyck wrote:
>> This patch is meant to improve overall system performance when making use of
>> the __phys_addr call. 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 significantly reduce the overall
>> size of the call. On my Xeon E5 system the entire __phys_addr inline call
>> consumes a little less than 32 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.
>>
>> 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.
> What kind of warning messages did you see?
> It's strange: sizeof(unsinged long) == sizeof(unsinged long long) on
> x86_64
One of the warnings is included below:
In file included from /usr/src/kernels/linux-next/arch/x86/include/asm/page_types.h:37,
from /usr/src/kernels/linux-next/arch/x86/include/asm/pgtable_types.h:5,
from /usr/src/kernels/linux-next/arch/x86/include/asm/boot.h:11,
from arch/x86/realmode/rm/../../boot/boot.h:26,
from arch/x86/realmode/rm/../../boot/regs.c:19,
from arch/x86/realmode/rm/regs.c:1:
/usr/src/kernels/linux-next/arch/x86/include/asm/page_64_types.h: In function '__phys_addr_nodebug':
/usr/src/kernels/linux-next/arch/x86/include/asm/page_64_types.h:63: warning: integer constant is too large for 'unsigned long' type
/usr/src/kernels/linux-next/arch/x86/include/asm/page_64_types.h:66: warning: integer constant is too large for 'unsigned long' type
/usr/src/kernels/linux-next/arch/x86/include/asm/page_64_types.h:66: warning: integer constant is too large for 'unsigned long' type
The warnings all seemed to originate from several different spots
throughout the x86 tree. All of the warning messages include
arch/x86/boot/boot.h:26 and then from there up the included from list is
always the same.
Thanks,
Alex
next prev parent reply other threads:[~2012-11-05 21:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 19:03 [PATCH v3 0/8] Improve performance of VM translation on x86_64 Alexander Duyck
2012-11-05 19:04 ` [PATCH v3 1/8] x86: Improve __phys_addr performance by making use of carry flags and inlining Alexander Duyck
2012-11-05 20:24 ` Kirill A. Shutemov
2012-11-05 21:56 ` Alexander Duyck [this message]
2012-11-05 22:08 ` Kirill A. Shutemov
2012-11-16 19:35 ` Alexander Duyck
2012-11-05 19:04 ` [PATCH v3 2/8] x86: Make it so that __pa_symbol can only process kernel symbols on x86_64 Alexander Duyck
2012-11-05 19:04 ` [PATCH v3 3/8] x86: Drop 4 unnecessary calls to __pa_symbol Alexander Duyck
2012-11-05 19:05 ` [PATCH v3 4/8] x86: Use __pa_symbol instead of __pa on C visible symbols Alexander Duyck
2012-11-05 19:05 ` [PATCH v3 5/8] x86/ftrace: " Alexander Duyck
2012-11-05 19:06 ` [PATCH v3 6/8] x86/xen: " Alexander Duyck
2012-11-06 15:45 ` Konrad Rzeszutek Wilk
2012-11-05 19:06 ` [PATCH v3 7/8] x86/acpi: " Alexander Duyck
2012-11-05 19:06 ` [PATCH v3 8/8] x86/lguest: " Alexander Duyck
2012-11-06 1:11 ` Rusty Russell
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=5098360C.6090805@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.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 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.