lkml.org 
[lkml]   [2015]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] arm64 updates for 4.4
On 11/6/15, 11:04 AM, Catalin Marinas wrote:

> On Fri, Nov 06, 2015 at 10:57:58AM +0100, Arnd Bergmann wrote:
>> On Thursday 05 November 2015 18:27:18 Catalin Marinas wrote:
>>> On Wed, Nov 04, 2015 at 02:55:01PM -0800, Linus Torvalds wrote:
>>>> On Wed, Nov 4, 2015 at 10:25 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>>> It's good for single-process loads - if you do a lot of big fortran
>>>> jobs, or a lot of big database loads, and nothing else, you're fine.
>>>
>>> These are some of the arguments from the server camp: specific
>>> workloads.

On our end, I asked our performance folks (and many others) about 3 or 4
years ago what they thought would make sense. The numbers suggested that
16KB might have been ideal (for specific targeted workloads), but since
that was optional in the architecture (as a later addition) that meant
"does not exist" as far as server/general purpose goes. Which lead to
more conversation, followed ultimately by the 64KB choice. The decision
to go to 64KB was in part based upon various discussion that suggested
this size was appropriate for workloads, but it is something that is
under evaluation. And obviously the number of threads on the topic is
not something that is ignored. 4KB with contiguous hint + huge pages
might well end up being the sweet spot in the longer term.

One of the purposes of Red Hat Enterprise Linux Server for ARM (RHELSA)
Development Preview (which I know just rolls off the tongue) is to test
the water with various decisions and see what works out, and what does
not. If 64KB does indeed turn out to be a poor decision then the page
size will be reverted to 4KB at some future time. But it is only once we
have some of the higher end mainstream systems running RHELSA (like we
do now) that we can start to actually look at real data and decide.

In addition to the TLB/hardware walker (micro)cache impact of page size
in terms of levels of walk through the tables (but we have cont. hint
and aggressive microcaches of interim levels to help us with this),
there is also the potential impact upon cache design. True we mostly
claim to be PIPT but underneath implementations might well be able to
optimize the (parallel) indexing stage given a larger page size. In many
conversations over the past few years with the architects building the
impending tsunami of high end v8 server cores, no objections have been
raised against the choice of 64KB in the first go around.

Anyway. We'll all watch and see :)

Jon.



\
 
 \ /
  Last update: 2015-11-25 06:41    [W:0.106 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site