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 9B161C2BA2B for ; Fri, 10 Apr 2020 09:05:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 61C08207FF for ; Fri, 10 Apr 2020 09:05:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 61C08207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41CCF8E0035; Fri, 10 Apr 2020 05:05:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F4BB8E0003; Fri, 10 Apr 2020 05:05:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30A218E0035; Fri, 10 Apr 2020 05:05:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 154148E0003 for ; Fri, 10 Apr 2020 05:05:42 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C7FE7942F for ; Fri, 10 Apr 2020 09:05:41 +0000 (UTC) X-FDA: 76691362482.04.jeans66_4ebe4f61ea904 X-HE-Tag: jeans66_4ebe4f61ea904 X-Filterd-Recvd-Size: 2849 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Fri, 10 Apr 2020 09:05:40 +0000 (UTC) IronPort-SDR: /UKP1B+G4S/zCom3uc+Y6Ft0+KFN4qvm465jlN/GtXC4aGR0Mgvbc1EP/kpSJt/2ID4SGG4wOg Pso4Evk9Ajxg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Apr 2020 02:05:39 -0700 IronPort-SDR: 5koKZhgqsRiqAtFio+WYudzEiO8/r2odNaHEURW+C0oHNqAiXyNhdP+kqwcfEQjK3xTACHsTei DGKLtwRT+C8g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,366,1580803200"; d="scan'208";a="297759669" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.23]) by FMSMGA003.fm.intel.com with ESMTP; 10 Apr 2020 02:05:37 -0700 From: "Huang\, Ying" To: Chintan Pandya Cc: Michal Hocko , Prathu Baronia , "akpm\@linux-foundation.org" , "linux-mm\@kvack.org" , "gregkh\@linuxfoundation.org" , "gthelen\@google.com" , "jack\@suse.cz" , Ken Lin , Gasine Xu Subject: Re: [RFC] mm/memory.c: Optimizing THP zeroing routine for !HIGHMEM cases References: <20200403081812.GA14090@oneplus.com> <20200403085201.GX22681@dhcp22.suse.cz> <20200409152913.GA9878@oneplus.com> <20200409154538.GR18386@dhcp22.suse.cz> Date: Fri, 10 Apr 2020 17:05:36 +0800 In-Reply-To: (Chintan Pandya's message of "Fri, 10 Apr 2020 07:00:34 +0000") Message-ID: <87lfn390db.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Chintan Pandya writes: >> I do realize that the initialization improvement patch doesn't really mention >> any real life usecase either. It is based on a microbenchmark but the objective >> sounds reasonable. If it regresses some other workloads then we either have to >> make it conditional or find out what is causing the regression and how much > > Generally, many architectures are optimized for serial loads, be it initialization or > access, as it is simplest form of prediction. Any random access pattern would kill > that pre-fetching. And for now, I suspect that to be the case here. Probably, we > can run more tests to confirm this part. Please prove your theory with test. Better to test x86 too. Best Regards, Huang, Ying