From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5584F17557 for ; Mon, 13 Jan 2025 15:47:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736783229; cv=none; b=RZM3ZE6bnM60tYaEyh2DANlL+fhYp/OQg4zsy854qmC8xVHTB1JKloVuOUPjlXs1GDf7ZViSwRcwxAl+joB/Fz2ek+yTQYpLSJPS20qTKnlhlteN2D1gZ9XiPwseF5z7CVUablY/yrC3B7Ur7DOeoctIJ25O69xEX4H2mOJ3/C8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736783229; c=relaxed/simple; bh=+YknnV67kdqrQWAWpbGFXKjvGOhWsHKJNs9zXEfDqI8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QCwJBycGFzoqsp8psh7tFy1sa5UWoeDrwG9WQQaRcuoKntFvNxvSmrjAK2ZhnstYPM/FVr+Qb8pWf7dBHqGONmONPxzOXXPGQAduje+8VGuamGy9j+sTSj+7KnDpK/gMJpe5IfTLGHeJE/JzUzPNo/mNM314C0I3+PqdDJ6TfaM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20230601.gappssmtp.com header.i=@cmpxchg-org.20230601.gappssmtp.com header.b=DEBEhLOe; arc=none smtp.client-ip=209.85.219.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20230601.gappssmtp.com header.i=@cmpxchg-org.20230601.gappssmtp.com header.b="DEBEhLOe" Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6dcdf23b4edso41316146d6.0 for ; Mon, 13 Jan 2025 07:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1736783224; x=1737388024; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+vxq4fvztjJv2PvKAdD8GFxCQjIi6fGEOFnZELMhweE=; b=DEBEhLOetfxtUuO+zto8Y23ZNEsKpfcr56YI+bmATza42ze1yY/vHuk3RIXNkqfWia 6W2CI50cP9NLFHDA8IhED0QfCOF5jRk6AfoEd2Rf/bORou2E5s5hxx6xci05kGCgkVRL Uh6+7sY2p7cAVtFuM0Md1UmYf3z2wwJ2Xr9sDKc5RpUyi4fq6BkFI0DXhJqV1ArWfIwA SgAj3lnq0I4TM2Udppgu2SFsM0Lv4s32sf0zAAWrfDT2Bsl20v7MlHHhtD1hNeEntXWc DsaPToN3xqSR29mnmNq0lOHogFhvR8FFXRD9C5HtpzEpFr2VqORpk7IC+dsUT0Oa4/GS X2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736783224; x=1737388024; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+vxq4fvztjJv2PvKAdD8GFxCQjIi6fGEOFnZELMhweE=; b=vlf6i/3D3epXVGxayU00RA08vkZTquTMIwniHRyuOERQJ7I9O0RXBOhO31XOthQi0J qAHTayF9gyCvxmsyQJV1MYWzpBLEgKOKzkJdtfY0oIjezqDdMyg4n+4//MV0yyPzSLb2 7EpwwJDclNxhpqdnX2DwIwah2sV7mQE6/fExwOYadf7qARL66yejogdhdfbQGAiw1YGl VQxhvl0LlNQ3IK9/gy4l+ej8g39Cd2xrVMbtA3dJGlMFikuvKU0qCG9jByzQ0aZOZHe4 GLeGVhtLr5aTvmu+50SDTNuyD+Z5gFy3O32qCU2RPX02ZaoYE7+8MVQIx6zF0GlzM3zZ ZfPw== X-Forwarded-Encrypted: i=1; AJvYcCX6soGWZ3SNUzqpd03aLsVKnFZ1zWD8bEXagbK+L1Lbee4kJcxSQCZNJrHfg76A1RaGiJQs0TEhNBHKTgg=@vger.kernel.org X-Gm-Message-State: AOJu0Yza3q2ynac354Qrym0z5CTMrTjdadb/j5RlVFRHS5SnQAKjBhWD sFH8Ha/5DjXrAaCd7jofvZUEpT/uw1LDu/VYZJLj4dORllh9oa5b3zjsGH1E8Q8= X-Gm-Gg: ASbGncu6bOCSQ5cnqmtXY9zLWJJbHDqTKu5Tux6geTuHeGXGTX1PqdMW1wU4YkslW/4 79hcCXE9PsL1rz/rkEffbcK2ZW/1s4ZQmf/SdNnj2vbT8bXqWlfkoUdlPaoiVR7xKR9Rsmw05jT GdCLTL1yuDr8ccXUPxmeBRYbv4YK2vFcFr0roAM6tbmU1jQGaOaDesFzSdXZYiAIKvkYh159JOc /msJPCBrj8i8GNa2OWlcHSOvNprzGfuW/ERHdQqQYVTUTyij5t3x0A= X-Google-Smtp-Source: AGHT+IHN09Tq4LaBfZti3SZjd3z+/R6bRDB5R1rHpJw59ofYzPffSx6Kxdc3LgosysowmJoqBMpoRA== X-Received: by 2002:a05:6214:2686:b0:6d4:36ff:4356 with SMTP id 6a1803df08f44-6df9b220effmr387333376d6.19.1736783222565; Mon, 13 Jan 2025 07:47:02 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dfad86056csm42585156d6.11.2025.01.13.07.47.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 07:47:01 -0800 (PST) Date: Mon, 13 Jan 2025 10:46:57 -0500 From: Johannes Weiner To: yangge1116@126.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, liuzixing@hygon.cn, Vlastimil Babka Subject: Re: [PATCH V3] mm: compaction: skip memory compaction when there are not enough migratable pages Message-ID: <20250113154657.GA829144@cmpxchg.org> References: <1736335854-548-1-git-send-email-yangge1116@126.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1736335854-548-1-git-send-email-yangge1116@126.com> CC Vlastimil On Wed, Jan 08, 2025 at 07:30:54PM +0800, yangge1116@126.com wrote: > From: yangge > > There are 4 NUMA nodes on my machine, and each NUMA node has 32GB > of memory. I have configured 16GB of CMA memory on each NUMA node, > and starting a 32GB virtual machine with device passthrough is > extremely slow, taking almost an hour. > > During the start-up of the virtual machine, it will call > pin_user_pages_remote(..., FOLL_LONGTERM, ...) to allocate memory. > Long term GUP cannot allocate memory from CMA area, so a maximum of > 16 GB of no-CMA memory on a NUMA node can be used as virtual machine > memory. There is 16GB of free CMA memory on a NUMA node, which is > sufficient to pass the order-0 watermark check, causing the > __compaction_suitable() function to consistently return true. > However, if there aren't enough migratable pages available, performing > memory compaction is also meaningless. Besides checking whether > the order-0 watermark is met, __compaction_suitable() also needs > to determine whether there are sufficient migratable pages available > for memory compaction. > > For costly allocations, because __compaction_suitable() always > returns true, __alloc_pages_slowpath() can't exit at the appropriate > place, resulting in excessively long virtual machine startup times. > Call trace: > __alloc_pages_slowpath > if (compact_result == COMPACT_SKIPPED || > compact_result == COMPACT_DEFERRED) > goto nopage; // should exit __alloc_pages_slowpath() from here > > When the 16G of non-CMA memory on a single node is exhausted, we will > fallback to allocating memory on other nodes. In order to quickly > fallback to remote nodes, we should skip memory compaction when > migratable pages are insufficient. After this fix, it only takes a > few tens of seconds to start a 32GB virtual machine with device > passthrough functionality. > > Signed-off-by: yangge > --- > > V3: > - fix build error > > V2: > - consider unevictable folios > > mm/compaction.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 07bd227..a9f1261 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -2383,7 +2383,27 @@ static bool __compaction_suitable(struct zone *zone, int order, > int highest_zoneidx, > unsigned long wmark_target) > { > + pg_data_t __maybe_unused *pgdat = zone->zone_pgdat; > + unsigned long sum, nr_pinned; > unsigned long watermark; > + > + sum = node_page_state(pgdat, NR_INACTIVE_FILE) + > + node_page_state(pgdat, NR_INACTIVE_ANON) + > + node_page_state(pgdat, NR_ACTIVE_FILE) + > + node_page_state(pgdat, NR_ACTIVE_ANON) + > + node_page_state(pgdat, NR_UNEVICTABLE); What about PAGE_MAPPING_MOVABLE pages that aren't on this list? For example, zsmalloc backend pages can be a large share of allocated memory, and they are compactable. You would give up on compaction prematurely and cause unnecessary allocation failures. That scenario is way more common than the one you're trying to fix. I think trying to make this list complete, and maintaining it, is painstaking and error prone. And errors are hard to detect: they will just manifest as spurious failures in higher order requests that you'd need to catch with tracing enabled in the right moments. So I'm not a fan of this approach. Compaction is already skipped when previous runs were not successful. See defer_compaction() and compaction_deferred(). Why is this not helping here? > + nr_pinned = node_page_state(pgdat, NR_FOLL_PIN_ACQUIRED) - > + node_page_state(pgdat, NR_FOLL_PIN_RELEASED); Likewise, as Barry notes, not all pinned pages are necessarily LRU pages. remap_vmalloc_range() pages come to mind. You can't do subset math on potentially disjunct sets. > + /* > + * Gup-pinned pages are non-migratable. After subtracting these pages, > + * we need to check if the remaining pages are sufficient for memory > + * compaction. > + */ > + if ((sum - nr_pinned) < (1 << order)) > + return false; > +