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;
From:   Song Liu <songliubraving@fb.com>
To:     William Kucharski <william.kucharski@oracle.com>
CC:     lkml <linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Bob Kasten <robert.a.kasten@intel.com>,
        "Mike Kravetz" <mike.kravetz@oracle.com>,
        Chad Mynhier <chad.mynhier@oracle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Johannes Weiner <jweiner@fb.com>,
        Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v3 0/2] mm,thp: Add filemap_huge_fault() for THP
Thread-Topic: [PATCH v3 0/2] mm,thp: Add filemap_huge_fault() for THP
Thread-Index: AQHVR3mCOKwnV56WUUyluRdig0XL86bkZvIA
Date:   Wed, 31 Jul 2019 08:35:46 +0000
Message-ID: <C9405E2A-4A0B-4EFD-B432-C54D2C9CFC2B@fb.com>
References: <20190731082513.16957-1-william.kucharski@oracle.com>
In-Reply-To: <20190731082513.16957-1-william.kucharski@oracle.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2E2A26E3179D714EACC580A7A1618AB3@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 63204fcb-963d-4141-b478-08d7159215bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 08:35:46.7934
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: songliubraving@fb.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1312
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-31_04:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1906280000 definitions=main-1907310092
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Jul 31, 2019, at 1:25 AM, William Kucharski <william.kucharski@oracle.=
com> wrote:
>=20
> This set of patches is the first step towards a mechanism for automatical=
ly
> mapping read-only text areas of appropriate size and alignment to THPs
> whenever possible.
>=20
> For now, the central routine, filemap_huge_fault(), amd various support
> routines are only included if the experimental kernel configuration optio=
n
>=20
> 	RO_EXEC_FILEMAP_HUGE_FAULT_THP
>=20
> is enabled.
>=20
> This is because filemap_huge_fault() is dependent upon the
> address_space_operations vector readpage() pointing to a routine that wil=
l
> read and fill an entire large page at a time without poulluting the page
> cache with PAGESIZE entries for the large page being mapped or performing
> readahead that would pollute the page cache entries for succeeding large
> pages. Unfortunately, there is no good way to determine how many bytes
> were read by readpage(). At present, if filemap_huge_fault() were to call
> a conventional readpage() routine, it would only fill the first PAGESIZE
> bytes of the large page, which is definitely NOT the desired behavior.
>=20
> However, by making the code available now it is hoped that filesystem
> maintainers who have pledged to provide such a mechanism will do so more
> rapidly.

Could you please explain how to test/try this? Would it automatically map
all executables to THPs?=20

Thanks,
Song=