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.7 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 A7D57C4CED0 for ; Mon, 23 Sep 2019 15:28:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6C27F20856 for ; Mon, 23 Sep 2019 15:28:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DIL1sv8H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C27F20856 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 D9B926B000A; Mon, 23 Sep 2019 11:28:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4CC86B000C; Mon, 23 Sep 2019 11:28:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C13DA6B0010; Mon, 23 Sep 2019 11:28:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 9EDD16B000A for ; Mon, 23 Sep 2019 11:28:12 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 4F6C08124 for ; Mon, 23 Sep 2019 15:28:12 +0000 (UTC) X-FDA: 75966566424.14.burn51_4797db8184b5c X-HE-Tag: burn51_4797db8184b5c X-Filterd-Recvd-Size: 5851 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Sep 2019 15:28:11 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id q1so34499845ion.1 for ; Mon, 23 Sep 2019 08:28:11 -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=ovt/JswJZVCgn7gC8S4lJscYd7cbBemmVRbh0mTK6j8=; b=DIL1sv8HFoMOCTvY7W467j9MaGY0XQ/cpfliC2FJd/FeyrcnifvBizVcCTvnyAFGIO cGheg0eSIIuJBVwN3y7Zr6AyEA6w42em57dkPqn/YBaIGXhMY+V3T02jinZJJdmndquZ wmQjkGFyh4MAxEMt95AnBtjAbpPBEgxpszO0c1Jhco2oTN/3BzvoJk4R22PEA65ByoAs hERyYTCJW35FEYvB9k5mPgTit9zhbKRMFJtM4CaQY7vGLmPJESVRCVfwVRRpWb6+zdws At0ZjLLmFGNozw0nE8OSV6p54JuOZl5KaOWm8llJUap4yEcI7FuKiYJbA9urGVmIhU1E iHoA== 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=ovt/JswJZVCgn7gC8S4lJscYd7cbBemmVRbh0mTK6j8=; b=ElfCa+fZS/TfxKbeZViaNNoyV26Pj9L2YP6KFWakQZwwHzQ160PZbaUO/D00ut63Kt bhfi7aAlTMRe6QGbvZWG9s+yMgQ2zrI9yY/zeLyUSNbGy6a8pwMz5FpWUKdaNTW/U/lN WW4d5B4tOtA+8VeC1+pgrFwYwjayU246T1c91+lRHoPtKWRhxc9gxZ7w5veHPkk1YNeA siY3/Gnzg1o8YVT34CkbgMrwjgwFOA8PO8kDaqrWYzGlFmeDpBPIJ4kTtUjtzZZuGz14 oStve9i3MshcoDjPWuaRz0ZA/QeL0iW1R6km5obR/LcPXYOfk9P4HnWljTyxdNCGEUOk ejyQ== X-Gm-Message-State: APjAAAX0phHt2StY6M8ZbqzLlBb3RgxH8O+D4XCO5sjJYSSGLs4LANlh uqp9QDZz0c/qs6OKQRilKK/HkZ9rkLOtesU0sas= X-Google-Smtp-Source: APXvYqy2qdjvGFEyVfH+HCnC4m6roo43HVkj5cfovY7yzUHvANgw9POBQ+vbh318GLdMzmTYpQDcuZxK3VD9smRReus= X-Received: by 2002:a5e:990f:: with SMTP id t15mr1173125ioj.270.1569252491032; Mon, 23 Sep 2019 08:28:11 -0700 (PDT) MIME-Version: 1.0 References: <20190918175109.23474.67039.stgit@localhost.localdomain> <20190918175249.23474.51171.stgit@localhost.localdomain> <20190923041330-mutt-send-email-mst@kernel.org> <20190923105746-mutt-send-email-mst@kernel.org> In-Reply-To: <20190923105746-mutt-send-email-mst@kernel.org> From: Alexander Duyck Date: Mon, 23 Sep 2019 08:28:00 -0700 Message-ID: Subject: Re: [PATCH v10 3/6] mm: Introduce Reported pages To: "Michael S. Tsirkin" Cc: virtio-dev@lists.oasis-open.org, kvm list , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , Michal Hocko , linux-mm , Vlastimil Babka , Andrew Morton , Mel Gorman , linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , Paolo Bonzini , Dan Williams , Alexander Duyck 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 Mon, Sep 23, 2019 at 8:00 AM Michael S. Tsirkin wrote: > > On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote: > > > > +static inline void > > > > +page_reporting_reset_boundary(struct zone *zone, unsigned int order, int mt) > > > > +{ > > > > + int index; > > > > + > > > > + if (order < PAGE_REPORTING_MIN_ORDER) > > > > + return; > > > > + if (!test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags)) > > > > + return; > > > > + > > > > + index = get_reporting_index(order, mt); > > > > + reported_boundary[index] = &zone->free_area[order].free_list[mt]; > > > > +} > > > > > > So this seems to be costly. > > > I'm guessing it's the access to flags: > > > > > > > > > /* zone flags, see below */ > > > unsigned long flags; > > > > > > /* Primarily protects free_area */ > > > spinlock_t lock; > > > > > > > > > > > > which is in the same cache line as the lock. > > > > I'm not sure what you mean by this being costly? > > I've just been wondering why does will it scale report a 1.5% regression > with this patch. Are you talking about data you have collected from a test you have run, or the data I have run? In the case of the data I have run I notice almost no difference as long as the pages are not actually being madvised. Once I turn on the madvise then I start seeing the regression, but almost all of that is due to page zeroing/faulting. There isn't expected to be a gain from this patchset until you start having guests dealing with memory overcommit on the host. Then at that point the patch set should start showing gains when the madvise bits are enabled in QEMU. Also the test I have been running is a modified version of the page_fault1 test to specifically target transparent huge pages in order to make this test that much more difficult, the standard page_fault1 test wasn't showing much of anything since the overhead for breaking a 2M page into 512 4K pages and zeroing those individually in the guest was essentially drowning out the effect of the patches themselves. - Alex