[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84e1698a-c85f-ee10-d367-2c203c6eea73@linux.intel.com>
Date: Fri, 9 Jun 2017 09:59:50 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Michal Hocko <mhocko@...nel.org>,
Laurent Dufour <ldufour@...ux.vnet.ibm.com>
Cc: paulmck@...ux.vnet.ibm.com, peterz@...radead.org,
akpm@...ux-foundation.org, kirill@...temov.name,
ak@...ux.intel.com, dave@...olabs.net, jack@...e.cz,
Matthew Wilcox <willy@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
haren@...ux.vnet.ibm.com, khandual@...ux.vnet.ibm.com,
npiggin@...il.com, bsingharora@...il.com
Subject: Re: [RFC v4 00/20] Speculative page faults
On 06/09/2017 09:35 AM, Michal Hocko wrote:
> On Fri 09-06-17 17:25:51, Laurent Dufour wrote:
> [...]
>> Thanks Michal for your feedback.
>>
>> I mostly focused on this database workload since this is the one where
>> we hit the mmap_sem bottleneck when running on big node. On my usual
>> victim node, I checked for basic usage like kernel build time, but I
>> agree that's clearly not enough.
>>
>> I try to find details about the 'kbench' you mentioned, but I didn't get
>> any valid entry.
>> Would you please point me on this or any other bench tool you think will
>> be useful here ?
>
> Sorry I meant kernbech (aka parallel kernel build). Other highly threaded
> workloads doing a lot of page faults and address space modification
> would be good to see as well. I wish I could give you much more
> comprehensive list but I am not very good at benchmarks.
>
Laurent,
Have you tried running the multi-fault microbenchmark by Kamezawa?
It does threaded page faults in parallel.
Peter ran that when he posted his specualtive page faults patches.
https://lkml.org/lkml/2010/1/6/28
Thanks.
Tim
Powered by blists - more mailing lists