From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D63EC3815B for ; Wed, 15 Apr 2020 11:09:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CC1C20732 for ; Wed, 15 Apr 2020 11:09:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CC1C20732 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F011C8E000C; Wed, 15 Apr 2020 07:09:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDADB8E0001; Wed, 15 Apr 2020 07:09:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9EAD8E000C; Wed, 15 Apr 2020 07:09:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id C1F2C8E0001 for ; Wed, 15 Apr 2020 07:09:48 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7054F824556B for ; Wed, 15 Apr 2020 11:09:48 +0000 (UTC) X-FDA: 76709819256.24.scene06_8fc830c1fd235 X-HE-Tag: scene06_8fc830c1fd235 X-Filterd-Recvd-Size: 3105 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Apr 2020 11:09:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3405DAC79; Wed, 15 Apr 2020 11:09:45 +0000 (UTC) Date: Wed, 15 Apr 2020 13:09:44 +0200 From: Michal Hocko To: "Huang, Ying" Cc: Alexander Duyck , Prathu Baronia , Chintan Pandya , akpm@linux-foundation.com, linux-mm , gregkh@linuxfoundation.com, Greg Thelen , jack@suse.cz, Ken Lin , Gasine Xu Subject: Re: [PATCH v2] mm: Optimized hugepage zeroing & copying from user Message-ID: <20200415110944.GG4629@dhcp22.suse.cz> References: <20200414153829.GA15230@oneplus.com> <20200414170312.GR4629@dhcp22.suse.cz> <20200414184743.GB2097@oneplus.com> <87mu7dza9x.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mu7dza9x.fsf@yhuang-dev.intel.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 15-04-20 11:40:42, Huang, Ying wrote: > Alexander Duyck writes: [...] > > If you take a look at commit c6ddfb6c58903 ("mm, clear_huge_page: move > > order algorithm into a separate function") they were running the tests > > on multiple threads simultaneously as their concern was flooding the > > LLC cache. I wonder if we couldn't look at bypassing the cache > > entirely using something like __copy_user_nocache for some portion of > > the copy and then only copy in the last pieces that we think will be > > immediately accessed. > > The problem is how to determine the size of the pieces that will be > immediately accessed? Well, this really depends. If you are in a page fault path then it should be quite obvious that at least the faulting subpage will be accessed. It is hard to make any assumptions beyond that. THP might behave very different from hugetlb pages because the former is an optimistic optimization and the rest of the page might not be used immediately. Hugetlb pages, on the other hand, are more likely to use a larger part of the page because then there is a clear memory loss. Then you have MAP_POPULATE or alike and then optimizing for future access sounds like a pointless exercise because this is essentially a stream initialization without any clue which memory will be used shortly. All that being said I am not against optimizing clear_huge_page but please stick to some real life usecases which actually benefit from the optimization. If there are any arch specific nuances then make them arch specific. Focusing on microbenchmarks is just leading to a complex code which might turn out suboptimal in some cases. -- Michal Hocko SUSE Labs