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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 19FD1C2BB1D for ; Tue, 17 Mar 2020 16:29:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD47420752 for ; Tue, 17 Mar 2020 16:29:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dgpB4Hfr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD47420752 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 555996B0005; Tue, 17 Mar 2020 12:29:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 506166B0006; Tue, 17 Mar 2020 12:29:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F44B6B0007; Tue, 17 Mar 2020 12:29:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 265716B0005 for ; Tue, 17 Mar 2020 12:29:18 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 10C1B180AD81A for ; Tue, 17 Mar 2020 16:29:18 +0000 (UTC) X-FDA: 76605389196.30.feast55_5126031186e55 X-HE-Tag: feast55_5126031186e55 X-Filterd-Recvd-Size: 8845 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Mar 2020 16:29:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584462556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yQFhJkeMlClPNzJr9WGcWOa+gyd2HFJg9MdUprRfJ3w=; b=dgpB4Hfrs9pjCuLWZ+6gg9/HlxST8k4PkWFmtRV4KhpSnjz+IwbIfAOo5hjdZgjxjjdsYm nqryBJtRHjVv4Ix6u4q/CxCku0H6A8pZlzMsuV8AeBHCEHS8oBZwoBaY6gFXVRq8YSTa1o FWufTmNSjyWXxfmRBIL42CFFIQJNq88= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-113-Gw1wofedMK2nvyA6t0Nqhg-1; Tue, 17 Mar 2020 12:29:15 -0400 X-MC-Unique: Gw1wofedMK2nvyA6t0Nqhg-1 Received: by mail-wr1-f72.google.com with SMTP id t4so6631754wrr.1 for ; Tue, 17 Mar 2020 09:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=hJ9IRxNEXJZnQrunYJpAkXFYXEUKw/iYEqZiM94FqR4=; b=j4dVGpHNZ5vWzQiBKbVzIgS9YXJKpMb0CZUzfrAi8ifzFtQt6hELismZgZWofMWMqW Iog/N6Z1RsNY4q7v1R379OtNGcgqZScLIqUfQkotjNdwdKMiGoUVN3yQ3Z7hQLiqmAxg 2IJZ8z6r1HQzUhrqwNI0lZhLZUFVrIF92tanz9o5IfiqPrhLkJ0QcMHO8jMcQzHF3zPO cJ/9jUSgHQXnOzJfHt82ub8Owq+oWZhqNDSSTPjHGTVaoKmBbV25ujw9yk7g7fu45Xm8 mL1iC04sTTZc/8j6MjC2oeYbHjFSQWePWPdM4Sr2ki9QULSfxapSNwnbYtgGdN0GY+Md Sc/Q== X-Gm-Message-State: ANhLgQ0pQXrSo/P7YZQy3uVO4WLJn3N+M3LKTzcwyU/QfRphkrMD7UxF g2vpxZgsizInb6n9+av9dQzX0xy9HByOe1xkI/azw5KTKiDBparRbQlrAMXs1m1TW84dBV9/6/q KAMQMxMJurlQ= X-Received: by 2002:a1c:4c16:: with SMTP id z22mr155400wmf.50.1584462553801; Tue, 17 Mar 2020 09:29:13 -0700 (PDT) X-Google-Smtp-Source: ADFU+vu7fxbd1NOj1Fd8X5IeMCfKPLtyDx4k9CrBADtVAaVO0WdO+/adOUSeBrq8Zo7JnejqPA35DQ== X-Received: by 2002:a1c:4c16:: with SMTP id z22mr155367wmf.50.1584462553538; Tue, 17 Mar 2020 09:29:13 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id 19sm4550594wma.3.2020.03.17.09.29.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 09:29:11 -0700 (PDT) From: Vitaly Kuznetsov To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-hyperv@vger.kernel.org, David Hildenbrand , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Andrew Morton , Michal Hocko , Oscar Salvador , "Rafael J. Wysocki" , Baoquan He , Wei Yang Subject: Re: [PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually In-Reply-To: <20200317104942.11178-6-david@redhat.com> References: <20200317104942.11178-1-david@redhat.com> <20200317104942.11178-6-david@redhat.com> Date: Tue, 17 Mar 2020 17:29:09 +0100 Message-ID: <877dzj3pyi.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: David Hildenbrand writes: > We get the MEM_ONLINE notifier call if memory is added right from the > kernel via add_memory() or later from user space. > > Let's get rid of the "ha_waiting" flag - the wait event has an inbuilt > mechanism (->done) for that. Initialize the wait event only once and > reinitialize before adding memory. Unconditionally call complete() and > wait_for_completion_timeout(). > > If there are no waiters, complete() will only increment ->done - which > will be reset by reinit_completion(). If complete() has already been > called, wait_for_completion_timeout() will not wait. > > There is still the chance for a small race between concurrent > reinit_completion() and complete(). If complete() wins, we would not > wait - which is tolerable (and the race exists in current code as > well). How can we see concurent reinit_completion() and complete()? Obvioulsy, we are not onlining new memory in kernel and hv_mem_hot_add() calls are serialized, we're waiting up to 5*HZ for the added block to come online before proceeding to the next one. Or do you mean we actually hit this 5*HZ timeout, proceeded to the next block and immediately after reinit_completion() we saw complete() for the previously added block? This is tolerable indeed, we're making forward progress (and this all is 'best effort' anyway). > > Note: We only wait for "some" memory to get onlined, which seems to be > good enough for now. > > Cc: "K. Y. Srinivasan" > Cc: Haiyang Zhang > Cc: Stephen Hemminger > Cc: Wei Liu > Cc: Andrew Morton > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: "Rafael J. Wysocki" > Cc: Baoquan He > Cc: Wei Yang > Cc: Vitaly Kuznetsov > Cc: linux-hyperv@vger.kernel.org > Signed-off-by: David Hildenbrand > --- > drivers/hv/hv_balloon.c | 25 ++++++++++--------------- > 1 file changed, 10 insertions(+), 15 deletions(-) > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c > index a02ce43d778d..af5e09f08130 100644 > --- a/drivers/hv/hv_balloon.c > +++ b/drivers/hv/hv_balloon.c > @@ -533,7 +533,6 @@ struct hv_dynmem_device { > =09 * State to synchronize hot-add. > =09 */ > =09struct completion ol_waitevent; > -=09bool ha_waiting; > =09/* > =09 * This thread handles hot-add > =09 * requests from the host as well as notifying > @@ -634,10 +633,7 @@ static int hv_memory_notifier(struct notifier_block = *nb, unsigned long val, > =09switch (val) { > =09case MEM_ONLINE: > =09case MEM_CANCEL_ONLINE: > -=09=09if (dm_device.ha_waiting) { > -=09=09=09dm_device.ha_waiting =3D false; > -=09=09=09complete(&dm_device.ol_waitevent); > -=09=09} > +=09=09complete(&dm_device.ol_waitevent); > =09=09break; > =20 > =09case MEM_OFFLINE: > @@ -726,8 +722,7 @@ static void hv_mem_hot_add(unsigned long start, unsig= ned long size, > =09=09has->covered_end_pfn +=3D processed_pfn; > =09=09spin_unlock_irqrestore(&dm_device.ha_lock, flags); > =20 > -=09=09init_completion(&dm_device.ol_waitevent); > -=09=09dm_device.ha_waiting =3D !memhp_auto_online; > +=09=09reinit_completion(&dm_device.ol_waitevent); > =20 > =09=09nid =3D memory_add_physaddr_to_nid(PFN_PHYS(start_pfn)); > =09=09ret =3D add_memory(nid, PFN_PHYS((start_pfn)), > @@ -753,15 +748,14 @@ static void hv_mem_hot_add(unsigned long start, uns= igned long size, > =09=09} > =20 > =09=09/* > -=09=09 * Wait for the memory block to be onlined when memory onlining > -=09=09 * is done outside of kernel (memhp_auto_online). Since the hot > -=09=09 * add has succeeded, it is ok to proceed even if the pages in > -=09=09 * the hot added region have not been "onlined" within the > -=09=09 * allowed time. > +=09=09 * Wait for memory to get onlined. If the kernel onlined the > +=09=09 * memory when adding it, this will return directly. Otherwise, > +=09=09 * it will wait for user space to online the memory. This helps > +=09=09 * to avoid adding memory faster than it is getting onlined. As > +=09=09 * adding succeeded, it is ok to proceed even if the memory was > +=09=09 * not onlined in time. > =09=09 */ > -=09=09if (dm_device.ha_waiting) > -=09=09=09wait_for_completion_timeout(&dm_device.ol_waitevent, > -=09=09=09=09=09=09 5*HZ); > +=09=09wait_for_completion_timeout(&dm_device.ol_waitevent, 5 * HZ); > =09=09post_status(&dm_device); > =09} > } > @@ -1707,6 +1701,7 @@ static int balloon_probe(struct hv_device *dev, > #ifdef CONFIG_MEMORY_HOTPLUG > =09set_online_page_callback(&hv_online_page); > =09register_memory_notifier(&hv_memory_nb); > +=09init_completion(&dm_device.ol_waitevent); > #endif > =20 > =09hv_set_drvdata(dev, &dm_device); Reviewed-by: Vitaly Kuznetsov --=20 Vitaly