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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EE8BC00140 for ; Mon, 8 Aug 2022 15:55:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D58036B0071; Mon, 8 Aug 2022 11:55:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE0606B0072; Mon, 8 Aug 2022 11:55:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B33BE6B0073; Mon, 8 Aug 2022 11:55:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9F4E46B0071 for ; Mon, 8 Aug 2022 11:55:13 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C6F5640A47 for ; Mon, 8 Aug 2022 15:55:12 +0000 (UTC) X-FDA: 79776874464.16.C5DE194 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf28.hostedemail.com (Postfix) with ESMTP id E2D45C014F for ; Mon, 8 Aug 2022 15:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659974112; x=1691510112; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=adBjDflubgueY7hGEhT8HFxQtuN3PdKVUrGiUqSnREU=; b=Bkv5c/fezXs2mAV9aBXDrAnLeM1cOonDJXESNm1NPui1JRF/nAB9YYwX u6Hy/FflT0L3axN31RQ7MY3FhJ/e9l27+O57DtchdVNJ+uqTYpfXpDe7Q 6aivzVb+AZZoLVtYnyullf/hwJeBf04AucSaxpq6SDXw+n/NA4b5QGeBt HVDYvxdqTQI3AtdmvUdQx3GGXGqjC223JmyBJpaESr66rZSalGN+nxF7m ENVDskU+IMQTNGCbE07LdQ8TjhNwc48ajJWrO7ehaXYa4Rd+jMOEESaX1 prBnl7+U9wXDFPK3rMJxoNT2SiwGiS4WU9nGR9D8P5m6lHNwILKH9hU16 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10433"; a="376920308" X-IronPort-AV: E=Sophos;i="5.93,222,1654585200"; d="scan'208";a="376920308" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2022 08:55:09 -0700 X-IronPort-AV: E=Sophos;i="5.93,222,1654585200"; d="scan'208";a="604416918" Received: from sankarka-mobl1.amr.corp.intel.com (HELO [10.212.251.15]) ([10.212.251.15]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2022 08:55:08 -0700 Message-ID: <4992c5b3-b9a9-b4ff-b09c-1383faf1ea6f@intel.com> Date: Mon, 8 Aug 2022 08:55:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv7 02/14] mm: Add support for unaccepted memory Content-Language: en-US To: Vlastimil Babka , David Hildenbrand , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport , Mel Gorman References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-3-kirill.shutemov@linux.intel.com> <8cf143e7-2b62-1a1e-de84-e3dcc6c027a4@suse.cz> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659974112; a=rsa-sha256; cv=none; b=BovNvZhRvDqX2J4dHTKFxGx/lrFipPpXawl9vSWXXnafTKO7fZm8BUWMxq77pI2uqZR3q9 aZNjCHz4Nt16NqzWEyCKDnL1Lq4KRthnnxAYxN5VOXMCYnZYIftOvmAd0d2mc3Yd9dUNHv 5v4YhaqrsHEwbEzbJ1UWwk4BMg7Mmn4= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="Bkv5c/fe"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659974112; h=from:from:sender: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:dkim-signature; bh=6593UEvPzzZzuVPj6o/mamF0G+9eMeMFfU1EhhoV9co=; b=fR76V9W6AoyBkK+Ey12SAyCaHZdmiSkE3SZvqCbDoF0qiU1JB1rGWYU9nKsE9KGSvWt51M +rqT6b3Bo6RMOxBIgZpwSSgwljh4yJ4G8fyKNHdGNS0TOHT49VgFz+PHzACbLnZVTMsP40 tET7F8WTQUbIEuc9Z1RTKk8WgkX7d8g= X-Rspamd-Server: rspam10 X-Stat-Signature: ps1wksbumu66fs94dpg8xi7e5tff58ok Authentication-Results: imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="Bkv5c/fe"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=dave.hansen@intel.com X-Rspam-User: X-Rspamd-Queue-Id: E2D45C014F X-HE-Tag: 1659974110-53612 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: On 8/5/22 11:17, Vlastimil Babka wrote: >> 3. Pull the page off the 2M/4M lists, drop the zone lock, accept it, >> then put it back. > Worth trying, IMHO. Perhaps easier to manage if the lists are distinct from > the normal ones, as I suggested. I was playing with another series recently where I did this, momentarily taking pages off some of the high-order lists and dropping the zone lock. Kirill, if you go looking at this, just make sure that you don't let this happen to too much memory at once. You might end up yanking memory out of the allocator that's not reflected in NR_FREE_PAGES. You might, for instance want to make sure that only a small number of threads can have pulled memory off the free lists at once. Something *logically* like this: // Limit to two threads at once: atomic_t nr_accepting_threads = ATOMIC_INIT(2); page = del_page_from_free_list(); if (!PageAccepted(page)) { if (atomic_dec_and_test(&nr_accepting_threads)) { // already at the thread limit add_page_from_free_list(page, ...); spin_unlock_irq(&zone->lock); // wait for a slot... spin_lock_irq(&zone->lock); goto retry; } else { spin_unlock_irq(&zone->lock); accept_page(page); spin_lock_irq(&zone->lock); add_page_from_free_list(page, ...); // do merging if it was a 2M page } } It's a little nasty because the whole thing is not a sleepable context. I also know that the merging code needs some refactoring if you want to do merging with 2M pages here. It might all get easier if you move all the page allocator stuff to only work at the 4M granularity. In any case, I'm not trying to dissuade anyone from listening to the other reviewer feedback. Just trying to save you a few cycles on a similar problem I was looking at recently.