Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp250438pxj; Thu, 17 Jun 2021 01:44:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLE0R8yiEB9d7O2M1oBFxbk6YFQy7sBpWpWYKJU5e1xy5Spvvpvb792cf+1SI5OIxbzOAB X-Received: by 2002:a17:907:a8b:: with SMTP id by11mr4101060ejc.357.1623919441395; Thu, 17 Jun 2021 01:44:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623919441; cv=none; d=google.com; s=arc-20160816; b=Xq9bcUDTUsctCkMspbGo/Y+0PM/eDQg57rPOzjfmAA2BPuMAEkHRoyBQNMUp9BG01c 5NVNfrhXIzNyYTa1h/jVn/KQyxXU+C4IRMrMuQFg9g7eX3mXgyFHP9VxLjGX0vHeWZ6w 7rQCjv0XXZ/NDV6/6Al/0lMt8iyr4H6qZi71DrqExtq0UdaoVnb+7F7QlaHEVX842+LU BhBpneOivCxrgn9O6jfh2CR4oxr+OX92MzCyu1/uHjZ4aOljOu8a+uDkoBX5wNUXi14f iynDp+itWL74qEkrz0/fSWRTE3ucFhk4zXH+wSU+VzmAmY3/uRUGXbK1xs21MF0S7d+X jOWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=sS6kybXx9hY6peXNH5/f9ArBP3605EB1bdQQ5Et7bb4=; b=e6B8cGnoX7OILsqgwd1nHBy7GTEHxttiPk2uCk/O8YTZLHW1r8WKSeLE6Zep3BK/a8 3Hhcoitbh5MzjVdpHIUtIA0siP+oIh7eqkIFGU9/ARwbH3AHhOco9izRD6FD3znyBI9B UI+4yD+vmLRvzy5dK00fh3MYBqtak895IVHGjYqiIZnLyaBXw+bZN7uvHyE5zGAB8sah 8SS5VkCd8ubiIfxvOYDHrNSYkrPrcAKJxKchO6VEZPtC9vSwSzeSyNWrdMeZYlEAJhkT AVQPXQXRALWVv1eL23ZHsafxgMNUHyH/kV9t320f8VmNbXVZKgV2LQXjigERx6w4hh2E jX0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BH3ca2tv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ce2si5171243ejc.316.2021.06.17.01.43.38; Thu, 17 Jun 2021 01:44:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BH3ca2tv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230136AbhFQIoo (ORCPT + 99 others); Thu, 17 Jun 2021 04:44:44 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54459 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229784AbhFQIon (ORCPT ); Thu, 17 Jun 2021 04:44:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623919356; 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=sS6kybXx9hY6peXNH5/f9ArBP3605EB1bdQQ5Et7bb4=; b=BH3ca2tvy7w+N2Q5cJSox6o2mSbzlby3hQ7JRc3+75fWwU0Qt7jmZAVg27erv6LV1kXQ0/ x61Ugi5rkk9bmWjOZ+VEdTP3wXrqYLHMC7uLG8lvobH+WCoc9ceco4B83NfQyX38AL7Svw f8wCDDx3ofq4fBmQzcuiIFscHfhKxys= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-473-LiQAtsP0NSOl8OzSLl1ddA-1; Thu, 17 Jun 2021 04:42:34 -0400 X-MC-Unique: LiQAtsP0NSOl8OzSLl1ddA-1 Received: by mail-wm1-f69.google.com with SMTP id t11-20020a05600c198bb02901bf95ba8642so1928887wmq.3 for ; Thu, 17 Jun 2021 01:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sS6kybXx9hY6peXNH5/f9ArBP3605EB1bdQQ5Et7bb4=; b=ba0T0mafdWEwq9kfGQWvPjYZc50l01CUjs4kaLfdCYZdFKq2U/+Z15cWHdg43KDwOX JbFmbueYW3tZovduAm/1GECrVfhGuq/iYO7jt+Xn+RvPUN+wJfv6SVDhPiKdGo03CcHY nwvZCdhxLecGge9r2W06sdUWj+N7YEcIUILaMUF0ITAWu3DgvT6SXlSReRdyXl/+xplg UA8qYWymw4kSZZ6FnuXsVPwtLmKSM9oBl40CBGAbvDxvKj5kE+zp/RDoTTghYUIHsz2s CiLu88xcRKIgOmmjsQYKEsoM0zAXUj0puKbjbDfSytsza2LAKzW+HuJxtXliaANtN5PG zh3A== X-Gm-Message-State: AOAM532smzrqx86C2xdpsGS+5ws9T7LzhfCYdnYmZTy8TGwda0hMi0Ur o4IYi7iuyY9aVvRksVQWsjKXWbu6fApxjbXzA6jEK08yem3FZ3KSAN7d22eEJEfytS6UB+IYzbW L97jqappXjnKYa+V/1CtR7aIA X-Received: by 2002:a5d:6a41:: with SMTP id t1mr4339148wrw.113.1623919353701; Thu, 17 Jun 2021 01:42:33 -0700 (PDT) X-Received: by 2002:a5d:6a41:: with SMTP id t1mr4339135wrw.113.1623919353505; Thu, 17 Jun 2021 01:42:33 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6170.dip0.t-ipconnect.de. [91.12.97.112]) by smtp.gmail.com with ESMTPSA id l10sm4681548wrv.82.2021.06.17.01.42.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 01:42:33 -0700 (PDT) Subject: Re: vmemmap alloc failure in hot_add_req() To: Nathan Chancellor Cc: "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , linux-hyperv@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador , Hillf Danton References: <20210612021115.2136-1-hdanton@sina.com> <951ddbaf-3d74-7043-4866-3809ff991cfd@redhat.com> From: David Hildenbrand Organization: Red Hat Message-ID: <98cba3fa-f787-081f-b833-cfea3a124254@redhat.com> Date: Thu, 17 Jun 2021 10:42:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > It does look like this kernel configuration has > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y. Okay, so then it's most likely really more of an issue with fragmented physical memory -- which is suboptimal but not a show blocker in your setup. (there are still cases where memory onlining can fail, especially with kasan running, but these are rather corner cases) > >> If it's not getting onlined, you easily sport after hotplug e.g., via >> "lsmem" that there are quite some offline memory blocks. >> >> Note that x86_64 code will fallback from populating huge pages to >> populating base pages for the vmemmap; this can happen easily when under >> memory pressure. > > Not sure if it is relevant or not but this warning can show up within a > minute of startup without me doing anything in particular. I remember that Hyper-V will start with a certain (configured) boot VM memory size and once the guest is up and running, use memory stats of the guest to decide whether to add (hotplug) or remove (balloon inflate) memory from the VM. So this could just be Hyper-V trying to apply its heuristics. > >> If adding memory would fail completely, you'd see another "hot_add >> memory failed error is ..." error message from hyper-v in the kernel >> log. If that doesn't show up, it's simply suboptimal, but hotplugging >> memory still succeeded. > > I did notice that from the code in hv_balloon.c but I do not think I > have ever seen that message in my logs. Okay, so at least hotplugging memory is working. -- Thanks, David / dhildenb