From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6150-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 57EB1985A54 for ; Mon, 23 Sep 2019 15:37:59 +0000 (UTC) Date: Mon, 23 Sep 2019 11:37:45 -0400 From: "Michael S. Tsirkin" Message-ID: <20190923113722-mutt-send-email-mst@kernel.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [virtio-dev] Re: [PATCH v10 3/6] mm: Introduce Reported pages To: Alexander Duyck 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 List-ID: On Mon, Sep 23, 2019 at 08:28:00AM -0700, Alexander Duyck wrote: > 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? About the kernel test robot auto report that was sent recently. > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org