Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4634967imm; Mon, 14 May 2018 10:17:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoa+WJHD3hjtKekD42u1SF56X5BKiPkce3etYp4JvxUx+upIpKUWOZL8OFOWBr9I/CtMvtz X-Received: by 2002:a62:e0cf:: with SMTP id d76-v6mr11425886pfm.52.1526318274620; Mon, 14 May 2018 10:17:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526318274; cv=none; d=google.com; s=arc-20160816; b=JeOatdG/61saFZZjetm1d597sdPyCVYPvWv9l3yxSw74AXU1LlAAmXIkNs4fchg/Wb Y3BxMcFNuDJOkVObfbUfleowvgRKlvmsF7/c8InSTXGlPCn1NKIFs+egze21JiRNOyzJ 2BcAxIJeAUSalBXDRpV7e/1+hKvS6vP9DU99jx0ndIsBe2pEH02WmsSmAWg9HjuC9YRw NWOxZwrlde6fzrVb0LUjIZQRxkZ4YNuNIPpZvRv44lCypPOvCXlhWSvit4cdjuseloJ3 STyOu8BlzwsHjf+g+7sf2daWbsWjqf7gGZUkfRz+BZC9wdm/pYbXzCqgB42DV3LLMqZ0 FNvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=5WHkuLEHVGkrNisIFlvRzc7FRe6IGGi85YLcewjEo78=; b=Q0wnmxG5UYDbc2q/i1T6P+fIyBhOliABgiH/dHwmhXjw22gc4+bnE2iDwuZ5Efy+vD VPFokYiJEjRmYFHKOdS9nseqSjAnoY8XREmLSYaqoEhDf/4KAy3PfDN2mLFonEKDvK1v jJeetkQ1oeNk+NL0wSepTJCbk7p+JVKXNmgv8e49RFDmz6ZMyO2WG/pWSLcAgENOPx01 +a3eHEgUP4CZKBeT3kCMwNoKnYfZbx5z+moKINhpkVjBe/tKMz/OTaiTkGD/s97pt28O LNfiuefuRgzWguid7h9I8JapWnuVKfhrpV4bOQbhMF3sKEaa9iatcmaXiQHGWVsUr8D0 hVfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=Al0MJe2p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2-v6si108115plh.136.2018.05.14.10.17.39; Mon, 14 May 2018 10:17:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=Al0MJe2p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753726AbeENPTh (ORCPT + 99 others); Mon, 14 May 2018 11:19:37 -0400 Received: from a9-54.smtp-out.amazonses.com ([54.240.9.54]:36840 "EHLO a9-54.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753080AbeENPTg (ORCPT ); Mon, 14 May 2018 11:19:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1526311175; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=5WHkuLEHVGkrNisIFlvRzc7FRe6IGGi85YLcewjEo78=; b=Al0MJe2pc9IB6CimpiEHLdXlyqbs/4umvSORFxdSWdXBMz1j+e1n9F+smM3zuCii MnjA1cNs4AJUK7dwTYUmt8Iog4JNsfZF26DssinpuQ0GDZu8FDMjJsfnXzM6L8v4Mq5 D8WJbD5sWf6BOE4SUzM8aY0g1BaaLdPvduNb3sYo= Date: Mon, 14 May 2018 15:19:34 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: William Kucharski cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC] mm, THP: Map read-only text segments using large THP pages In-Reply-To: <5BB682E1-DD52-4AA9-83E9-DEF091E0C709@oracle.com> Message-ID: <010001635f3c42d3-ed92871f-4fba-47dc-9750-69a40dd07ab6-000000@email.amazonses.com> References: <5BB682E1-DD52-4AA9-83E9-DEF091E0C709@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2018.05.14-54.240.9.54 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 May 2018, William Kucharski wrote: > The idea is that the kernel will attempt to allocate and map the range using a > PMD sized THP page upon first fault; if the allocation is successful the page > will be populated (at present using a call to kernel_read()) and the page will > be mapped at the PMD level. If memory allocation fails, the page fault routines > will drop through to the conventional PAGESIZE-oriented routines for mapping > the faulting page. Cool. This could be controlled by the faultaround logic right? If we get fault_around_bytes up to huge page size then it is reasonable to use a huge page direcly. fault_around_bytes can be set via sysfs so there is a natural way to control this feature there I think. > Since this approach will map a PMD size block of the memory map at a time, we > should see a slight uptick in time spent in disk I/O but a substantial drop in > page faults as well as a reduction in iTLB misses as address ranges will be > mapped with the larger page. Analysis of a test program that consists of a very > large text area (483,138,032 bytes in size) that thrashes D$ and I$ shows this > does occur and there is a slight reduction in program execution time. I think we would also want such a feature for regular writable pages as soon as possible.