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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 CD752C2BB1D for ; Tue, 14 Apr 2020 19:33:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8168C2074D for ; Tue, 14 Apr 2020 19:33:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dsPTLEdQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8168C2074D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2A24F8E000E; Tue, 14 Apr 2020 15:33:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2529E8E0001; Tue, 14 Apr 2020 15:33:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11C488E000E; Tue, 14 Apr 2020 15:33:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id EBA988E0001 for ; Tue, 14 Apr 2020 15:33:09 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A369F181AEF0B for ; Tue, 14 Apr 2020 19:33:09 +0000 (UTC) X-FDA: 76707458898.29.trees55_72d95ad391c51 X-HE-Tag: trees55_72d95ad391c51 X-Filterd-Recvd-Size: 6591 Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 19:33:09 +0000 (UTC) Received: by mail-il1-f196.google.com with SMTP id i75so876258ild.13 for ; Tue, 14 Apr 2020 12:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lf5bjI5rvj4KRUMErDCfjK/wsFZ+BJZFwyn7nk6/iA4=; b=dsPTLEdQNI+wATSKFvSP+GXmFfEdlKvnbaKIEMrGC5KKNfWwczHC2ZgygNLukMqBbm dsyJD3Lnxyy/Yod13jYvirhRIWUFaV2Sx3OP56XBroAnYHVCis3aeq1CYk440oTcnFuS 3T47srjEDWOXf3c6uMTKwp+ZEaLX/+BnfTaLK+oHy+2W9ripbDwl2sqnndYXfTtpjwEZ lNW1v0o29y5c+1sropyZw9VO4iukx5yKThGtKloN9J/YUGYBxURjxnuWZoN7Q/ed71Ld W1ePeDGoPSCI6pyqCzS/HXvyag8bTRIdnAnG3W71eeYS5s5wm6jJX5/VutsdsHgI6Cli IL5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lf5bjI5rvj4KRUMErDCfjK/wsFZ+BJZFwyn7nk6/iA4=; b=ToBHXFTdVg1CPXS6INoJsf3Dv9RR/Cn135JKiN6RJ4/osuf2vR0CjxIPxnshJjF32R DbJQqlcBOkaeP19qCBDQ2hC3cJet1cVmQyYqwjw3PxXn6u32rHHWR3TuHY8Raewjo8Qb fLTqDbjN2V7bZQpASevlWvMVZvdZgc52bUDRhFGNTaQLavW6T9zAnQNzwYzalXycq9uW SnLW1TXb9E0zUcJEJI1hwMtE+W4lB6OXppQHxmikcKyVaKs9Fnpf3w0kDZJNdO2Fs2Ya jjVc7pMwQmltCanbKatt76anZFSZRm1uI2SPh4PvEhyZsVV1jjJmO3GMCeMjKrag8Z4k 4mbw== X-Gm-Message-State: AGi0PuZ/j9z57a0cFLQBwR96qrxjIlAuC5ko/d9/6FGAY9iEG6m/sM5k DkZul6t1iEF6W5qrVN8T5zGLGLTKwGChkGB4u/s= X-Google-Smtp-Source: APiQypJvOdODEcAmX40M69d0nYHrsm3P1MGP85YISuYYgVeSOr3AhU8FcBFXlxAjPqdNQaGQsD2EzuuUkoj8Vf+RM2E= X-Received: by 2002:a92:4b11:: with SMTP id m17mr1984990ilg.42.1586892788431; Tue, 14 Apr 2020 12:33:08 -0700 (PDT) MIME-Version: 1.0 References: <20200414153829.GA15230@oneplus.com> <20200414170312.GR4629@dhcp22.suse.cz> <20200414184743.GB2097@oneplus.com> In-Reply-To: <20200414184743.GB2097@oneplus.com> From: Alexander Duyck Date: Tue, 14 Apr 2020 12:32:57 -0700 Message-ID: Subject: Re: [PATCH v2] mm: Optimized hugepage zeroing & copying from user To: Prathu Baronia Cc: Michal Hocko , Chintan Pandya , "Huang, Ying" , akpm@linux-foundation.com, linux-mm , gregkh@linuxfoundation.com, Greg Thelen , jack@suse.cz, Ken Lin , Gasine Xu Content-Type: text/plain; charset="UTF-8" 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 Tue, Apr 14, 2020 at 11:47 AM Prathu Baronia wrote: > > The 04/14/2020 19:03, Michal Hocko wrote: > > I still have hard time to see why kmap machinery should introduce any > > slowdown here. Previous data posted while discussing v1 didn't really > > show anything outside of the noise. > > > You are right, the multiple barriers are not responsible for the slowdown, but > removal of kmap_atomic() allows us to call memset and memcpy for larger sizes. > I will re-frame this part of the commit text when we proceed towards v3 to > present it more cleanly. > > > > It would be really nice to provide std > > > Here is the data with std:- > ---------------------------------------------------------------------- > Results: > ---------------------------------------------------------------------- > Results for ARM64 target (SM8150 , CPU0 & 6 are online, running at max > frequency) > All numbers are mean of 100 iterations. Variation is ignorable. > ---------------------------------------------------------------------- > - Oneshot : 3389.26 us std: 79.1377 us > - Forward : 8876.16 us std: 172.699 us > - Reverse : 18157.6 us std: 111.713 us > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > Results for x86-64 (Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, only CPU 0 in > max frequency, DDR also running at max frequency.) All numbers are mean of > 100 iterations. Variation is ignorable. > ---------------------------------------------------------------------- > - Oneshot : 3203.49 us std: 115.4086 us > - Forward : 5766.46 us std: 328.6299 us > - Reverse : 5187.86 us std: 341.1918 us > ---------------------------------------------------------------------- > > > > > No. There is absolutely zero reason to add a config option for this. The > > kernel should have all the information to make an educated guess. > > > I will try to incorporate this in v3. But currently I don't have any idea on how > to go about implementing the guessing logic. Would really appreciate if you can > suggest some way to go about it. > > > Also before going any further. The patch which has introduced the > > optimization was c79b57e462b5 ("mm: hugetlb: clear target sub-page last > > when clearing huge page"). It is based on an artificial benchmark which > > to my knowledge doesn't represent any real workload. Your measurements > > are based on a different benchmark. Your numbers clearly show that some > > assumptions used for the optimization are not architecture neutral. > > > But oneshot numbers are significantly better on both the archs. I think > theoretically the oneshot approach should provide better results on all the > architectures when compared with serial approach. Isn't it a fair assumption to > go ahead with the oneshot approach? I think the point that Michal is getting at is that there are other tests that need to be run. You are running the test on just one core. What happens as we start fanning this out and having multiple instances running per socket? We would be flooding the LLC in addition to overwriting all the other caches. 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.