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 2770AC7618B for ; Fri, 26 Jul 2019 16:41:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0541722BF5 for ; Fri, 26 Jul 2019 16:41:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727163AbfGZQlM (ORCPT ); Fri, 26 Jul 2019 12:41:12 -0400 Received: from mga17.intel.com ([192.55.52.151]:37330 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725298AbfGZQlM (ORCPT ); Fri, 26 Jul 2019 12:41:12 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 09:38:08 -0700 X-IronPort-AV: E=Sophos;i="5.64,311,1559545200"; d="scan'208";a="175655606" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 09:38:08 -0700 Message-ID: Subject: Re: [PATCH v2 4/5] mm: Introduce Hinted pages From: Alexander Duyck To: Nitesh Narayan Lal , Alexander Duyck , kvm@vger.kernel.org, david@redhat.com, mst@redhat.com, dave.hansen@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: yang.zhang.wz@gmail.com, pagupta@redhat.com, riel@surriel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com Date: Fri, 26 Jul 2019 09:38:08 -0700 In-Reply-To: <49a49a38-b1f4-d5c0-f5f1-a6bed57a03d2@redhat.com> References: <20190724165158.6685.87228.stgit@localhost.localdomain> <20190724170259.6685.18028.stgit@localhost.localdomain> <49a49a38-b1f4-d5c0-f5f1-a6bed57a03d2@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, 2019-07-26 at 08:24 -0400, Nitesh Narayan Lal wrote: > On 7/24/19 1:03 PM, Alexander Duyck wrote: > > From: Alexander Duyck > > > > > > +/* > > + * The page hinting cycle consists of 4 stages, fill, react, drain, and idle. > > + * We will cycle through the first 3 stages until we fail to obtain any > > + * pages, in that case we will switch to idle. > > + */ > > +static void page_hinting_cycle(struct zone *zone, > > + struct page_hinting_dev_info *phdev) > > +{ > > + /* > > + * Guarantee boundaries and stats are populated before we > > + * start placing hinted pages in the zone. > > + */ > > + if (page_hinting_populate_metadata(zone)) > > + return; > > + > > + spin_lock(&zone->lock); > > + > > + /* set bit indicating boundaries are present */ > > + set_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags); > > + > > + do { > > + /* Pull pages out of allocator into a scaterlist */ > > + unsigned int num_hints = page_hinting_fill(zone, phdev); > > + > > + /* no pages were acquired, give up */ > > + if (!num_hints) > > + break; > > + > > + spin_unlock(&zone->lock); > > Is there any recommendation in general about how/where we should lock and unlock > zones in the code? For instance, over here you have a zone lock outside the loop > and you are unlocking it inside the loop and then re-acquiring it. > My guess is we should be fine as long as: > 1. We are not holding the lock for a very long time. > 2. We are making sure that if we have a zone lock we are releasing it before > returning from the function. So as a general rule the first two you mention work. Basically what you want to do is work with some sort of bounded limit when you are holding the lock so you know it will be released in a timely fashion. The reason for dropping the lock inside of the loop s because we will end up sleeping while we wait for the virtio-balloon device to process the pages. So it makes sense to release the lock, process the pages, and then reacquire the lock so that we can return the pages and grab another 16 pages.