Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752389AbdFMKUK (ORCPT ); Tue, 13 Jun 2017 06:20:10 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55631 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbdFMKUJ (ORCPT ); Tue, 13 Jun 2017 06:20:09 -0400 Subject: Re: [RFC v4 00/20] Speculative page faults To: Tim Chen , Michal Hocko Cc: paulmck@linux.vnet.ibm.com, peterz@infradead.org, akpm@linux-foundation.org, kirill@shutemov.name, ak@linux.intel.com, dave@stgolabs.net, jack@suse.cz, Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, haren@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com, npiggin@gmail.com, bsingharora@gmail.com References: <1497018069-17790-1-git-send-email-ldufour@linux.vnet.ibm.com> <20170609150126.GI21764@dhcp22.suse.cz> <83cf1566-3e76-d3fa-10a8-d83bbf9fd568@linux.vnet.ibm.com> <20170609163520.GB9332@dhcp22.suse.cz> <84e1698a-c85f-ee10-d367-2c203c6eea73@linux.intel.com> From: Laurent Dufour Date: Tue, 13 Jun 2017 12:19:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <84e1698a-c85f-ee10-d367-2c203c6eea73@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17061310-0040-0000-0000-000003A89EB3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061310-0041-0000-0000-000025A17C57 Message-Id: <98b890bc-10f7-d049-22a4-fe18c712af8d@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-13_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130184 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1281 Lines: 32 On 09/06/2017 18:59, Tim Chen wrote: > 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 to remind me about this, I downloaded and built it a time ago and forget about it. I'll give it another try !