From: Tejun Heo <tj@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Toshi Kani <toshi.kani@hp.com>,
Zhang Yanfei <zhangyanfei.yes@gmail.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
konrad.wilk@oracle.com, robert.moore@intel.com,
lv.zheng@intel.com, rjw@sisk.pl, lenb@kernel.org,
tglx@linutronix.de, mingo@elte.hu, akpm@linux-foundation.org,
trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, laijs@cn.fujitsu.com,
isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
mgorman@suse.de, minchan@kernel.org, mina86@mina86.com,
gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com,
lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com,
prarit@redhat.com, zhangyanfei@cn.fujitsu.com,
yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
Date: Fri, 23 Aug 2013 10:57:32 -0400 [thread overview]
Message-ID: <20130823145732.GC3277@htj.dyndns.org> (raw)
In-Reply-To: <20130823143507.GB3277@htj.dyndns.org>
On Fri, Aug 23, 2013 at 10:35:07AM -0400, Tejun Heo wrote:
> Yeah, it's true that MTRRs are nasty. On the other hand, we've been
> doing that for over a decade and are still doing it anyway if I'm not
> mistaken. It probably isn't a big difference but it's still a bit sad
> that this is likely causing small performance regression out in the
> wild.
Just went over the processor manual and it doesn't seem like doing the
above would be a good idea.
System Programming Guide, Part 1
11.11.9 Large Page Size Considerations
...
Because the memory type for a large page is cached in the TLB, the
processor can behave in an undefined manner if a large page is mapped
to a region of memory that MTRRs have mapped with multiple memory
types.
...
If a large page maps to a region of memory containing different
MTRR-defined memory types, the PCD and PWT flags in the page-table
entry should be set for the most conservative memory type for that
range. For example, a large page used for memory mapped I/O and
regular memory 11-48 Vol. 3A MEMORY CACHE CONTROL
...
The Pentium 4, Intel Xeon, and P6 family processors provide special
support for the physical memory range from 0 to 4 MBytes,
...
Here, the processor maps the memory range as multiple 4-KByte pages
within the TLB. This operation insures correct behavior at the cost
of performance. To avoid this performance penalty, operating-system
software should reserve the large page option for regions of memory
at addresses greater than or equal to 4 MBytes.
So, yeah, the current behavior seems like the right thing to do.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Toshi Kani <toshi.kani@hp.com>,
Zhang Yanfei <zhangyanfei.yes@gmail.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
konrad.wilk@oracle.com, robert.moore@intel.com,
lv.zheng@intel.com, rjw@sisk.pl, lenb@kernel.org,
tglx@linutronix.de, mingo@elte.hu, akpm@linux-foundation.org,
trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, laijs@cn.fujitsu.com,
isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
mgorman@suse.de, minchan@kernel.org, mina86@mina86.com,
gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com,
lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com,
prarit@redhat.com, zhangyanfei@cn.fujitsu.com,
yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
Date: Fri, 23 Aug 2013 10:57:32 -0400 [thread overview]
Message-ID: <20130823145732.GC3277@htj.dyndns.org> (raw)
In-Reply-To: <20130823143507.GB3277@htj.dyndns.org>
On Fri, Aug 23, 2013 at 10:35:07AM -0400, Tejun Heo wrote:
> Yeah, it's true that MTRRs are nasty. On the other hand, we've been
> doing that for over a decade and are still doing it anyway if I'm not
> mistaken. It probably isn't a big difference but it's still a bit sad
> that this is likely causing small performance regression out in the
> wild.
Just went over the processor manual and it doesn't seem like doing the
above would be a good idea.
System Programming Guide, Part 1
11.11.9 Large Page Size Considerations
...
Because the memory type for a large page is cached in the TLB, the
processor can behave in an undefined manner if a large page is mapped
to a region of memory that MTRRs have mapped with multiple memory
types.
...
If a large page maps to a region of memory containing different
MTRR-defined memory types, the PCD and PWT flags in the page-table
entry should be set for the most conservative memory type for that
range. For example, a large page used for memory mapped I/O and
regular memory 11-48 Vol. 3A MEMORY CACHE CONTROL
...
The Pentium 4, Intel Xeon, and P6 family processors provide special
support for the physical memory range from 0 to 4 MBytes,
...
Here, the processor maps the memory range as multiple 4-KByte pages
within the TLB. This operation insures correct behavior at the cost
of performance. To avoid this performance penalty, operating-system
software should reserve the large page option for regions of memory
at addresses greater than or equal to 4 MBytes.
So, yeah, the current behavior seems like the right thing to do.
Thanks.
--
tejun
next prev parent reply other threads:[~2013-08-23 14:57 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 10:15 [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 1/8] x86: Make get_ramdisk_{image|size}() global Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 2/8] x86, microcode: Use get_ramdisk_{image|size}() in microcode handling Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 3/8] x86, acpi: Move table_sigs[] to stack Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 4/8] x86, acpi, brk: Extend BRK 256KB to store acpi override tables Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 5/8] x86, brk: Make extend_brk() available with va/pa Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 12:26 ` Konrad Rzeszutek Wilk
2013-08-21 12:26 ` Konrad Rzeszutek Wilk
2013-08-21 12:35 ` H. Peter Anvin
2013-08-21 12:35 ` H. Peter Anvin
2013-08-21 14:42 ` Konrad Rzeszutek Wilk
2013-08-21 14:42 ` Konrad Rzeszutek Wilk
2013-08-21 15:04 ` H. Peter Anvin
2013-08-21 15:04 ` H. Peter Anvin
2013-08-21 10:15 ` [PATCH 6/8] x86, acpi: Make acpi_initrd_override() available with va or pa Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 7/8] x86, acpi, brk: Make early_alloc_acpi_override_tables_buf() available with va/pa Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:15 ` [PATCH 8/8] x86, acpi: Do acpi_initrd_override() earlier in head_32.S/head64.c Tang Chen
2013-08-21 10:15 ` Tang Chen
2013-08-21 10:42 ` [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier Tang Chen
2013-08-21 10:42 ` Tang Chen
2013-08-21 13:06 ` Tejun Heo
2013-08-21 13:06 ` Tejun Heo
2013-08-21 15:00 ` Zhang Yanfei
2013-08-21 15:00 ` Zhang Yanfei
2013-08-21 15:36 ` Tejun Heo
2013-08-21 15:36 ` Tejun Heo
2013-08-21 19:31 ` Toshi Kani
2013-08-21 19:31 ` Toshi Kani
2013-08-21 19:54 ` Tejun Heo
2013-08-21 19:54 ` Tejun Heo
2013-08-21 20:29 ` Toshi Kani
2013-08-21 20:29 ` Toshi Kani
2013-08-21 20:40 ` Tejun Heo
2013-08-21 20:40 ` Tejun Heo
2013-08-21 22:36 ` Toshi Kani
2013-08-21 22:36 ` Toshi Kani
2013-08-22 3:32 ` Tejun Heo
2013-08-22 3:32 ` Tejun Heo
2013-08-22 15:52 ` Toshi Kani
2013-08-22 15:52 ` Toshi Kani
2013-08-22 18:31 ` Tejun Heo
2013-08-22 18:31 ` Tejun Heo
2013-08-22 19:39 ` Zhang Yanfei
2013-08-22 19:39 ` Zhang Yanfei
2013-08-22 19:45 ` Tejun Heo
2013-08-22 19:45 ` Tejun Heo
2013-08-22 20:11 ` Toshi Kani
2013-08-22 20:11 ` Toshi Kani
2013-08-22 20:21 ` Tejun Heo
2013-08-22 20:21 ` Tejun Heo
2013-08-22 20:35 ` Tejun Heo
2013-08-22 20:35 ` Tejun Heo
2013-08-22 21:06 ` Toshi Kani
2013-08-22 21:06 ` Toshi Kani
2013-08-22 21:21 ` Tejun Heo
2013-08-22 21:21 ` Tejun Heo
2013-08-22 22:17 ` Toshi Kani
2013-08-22 22:17 ` Toshi Kani
2013-08-23 13:04 ` Tejun Heo
2013-08-23 13:04 ` Tejun Heo
2013-08-23 13:08 ` H. Peter Anvin
2013-08-23 13:08 ` H. Peter Anvin
2013-08-23 14:19 ` Tejun Heo
2013-08-23 14:19 ` Tejun Heo
2013-08-23 14:24 ` H. Peter Anvin
2013-08-23 14:24 ` H. Peter Anvin
2013-08-23 14:24 ` H. Peter Anvin
2013-08-23 14:35 ` Tejun Heo
2013-08-23 14:35 ` Tejun Heo
2013-08-23 14:57 ` Tejun Heo [this message]
2013-08-23 14:57 ` Tejun Heo
2013-08-23 16:14 ` Toshi Kani
2013-08-23 16:14 ` Toshi Kani
2013-08-23 16:24 ` Tejun Heo
2013-08-23 16:24 ` Tejun Heo
2013-08-23 17:13 ` Toshi Kani
2013-08-23 17:13 ` Toshi Kani
2013-08-23 17:29 ` Zhang Yanfei
2013-08-23 17:29 ` Zhang Yanfei
2013-08-23 16:54 ` Zhang Yanfei
2013-08-23 16:54 ` Zhang Yanfei
2013-08-23 18:18 ` Yinghai Lu
2013-08-23 18:18 ` Yinghai Lu
2013-08-23 18:25 ` H. Peter Anvin
2013-08-23 20:08 ` Yinghai Lu
2013-08-23 20:30 ` Russ Anderson
2013-08-23 20:48 ` Yinghai Lu
2013-08-23 21:50 ` chen tang
2013-08-23 21:52 ` Moore, Robert
2013-08-23 22:05 ` Yinghai Lu
2013-08-23 22:08 ` Yinghai Lu
2013-08-23 22:40 ` chen tang
2013-08-23 23:04 ` Yinghai Lu
2013-08-24 2:41 ` Russ Anderson
2013-08-23 20:33 ` chen tang
2013-08-23 20:33 ` chen tang
2013-08-23 21:08 ` Yinghai Lu
2013-08-23 21:08 ` Yinghai Lu
2013-08-23 22:27 ` chen tang
2013-08-23 22:27 ` chen tang
2013-08-23 18:29 ` Toshi Kani
2013-08-23 18:29 ` Toshi Kani
2013-08-23 21:37 ` chen tang
2013-08-23 21:37 ` chen tang
2013-08-23 21:52 ` Tejun Heo
2013-08-23 21:52 ` Tejun Heo
2013-08-23 23:56 ` chen tang
2013-08-23 23:56 ` chen tang
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=20130823145732.GC3277@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gong.chen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=jweiner@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=laijs@cn.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lv.zheng@intel.com \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=mingo@elte.hu \
--cc=prarit@redhat.com \
--cc=riel@redhat.com \
--cc=rjw@sisk.pl \
--cc=robert.moore@intel.com \
--cc=tangchen@cn.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=trenn@suse.de \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.org \
--cc=yanghy@cn.fujitsu.com \
--cc=yinghai@kernel.org \
--cc=zhangyanfei.yes@gmail.com \
--cc=zhangyanfei@cn.fujitsu.com \
/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.