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 77CFEC3DA42 for ; Wed, 17 Jul 2024 07:19:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDB316B0088; Wed, 17 Jul 2024 03:19:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E64966B008C; Wed, 17 Jul 2024 03:19:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2C0A6B0095; Wed, 17 Jul 2024 03:19:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B3CFB6B0088 for ; Wed, 17 Jul 2024 03:19:17 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 531541A17DF for ; Wed, 17 Jul 2024 07:19:17 +0000 (UTC) X-FDA: 82348393554.15.A4882CF Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf19.hostedemail.com (Postfix) with ESMTP id 59BC81A0009 for ; Wed, 17 Jul 2024 07:19:15 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=cnY2lqYx; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721200716; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ArgSkToA2nsjWvuTjSuyJoQaI0tJr7zvtfDgU/aUVoY=; b=IMG2TFI5FJj8J1OnhlVjJlEY1o7hapYuXe3b038XE/pdS2siHZfoG/2J+b6lBCmrMMEltJ xd62QpIAzr+A8nMi/jingjuoGqYVYp9ck9fkGnNhpqqhIadqitVmLUTNG59l8Nczfp1Hhz OaOXHJ/UoPNXjdOJIJiA+5tTDu5f/hY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721200716; a=rsa-sha256; cv=none; b=G6xUUWq8EPJSyH/J6MKvx8JZHBCOfCtFiVQv1fg6+z9kaq7904v0ogFr6uO5ITIfGawvWx Zg8a7tOy/vEVYayOHRPpSafz8iYfIokzH1NbjW1SXPymXn29lta2PAs79SA6/gXPBaWx/x lVu8tTMD1u41pISpoemyeGLVwQ7ukAk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=cnY2lqYx; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a77c1658c68so673551766b.0 for ; Wed, 17 Jul 2024 00:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721200754; x=1721805554; darn=kvack.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=ArgSkToA2nsjWvuTjSuyJoQaI0tJr7zvtfDgU/aUVoY=; b=cnY2lqYxhBn7q69PewOJHVqNZJDajKPt/L5I9gxE8xIDar17+eGCPnFXcQvjHgzs5y DZsFbpJoA30987uFoNOc4WKc+tHFtc6qbCpQD4mnuA16ZDGECS2RkM5rRW5IF1hA7tZv 2kY7SDNMg69MpULfzGYozrJNB/myvlwm5dC1R6u4BbToQ2Sx4QVjpvQFn1AjK0t94PMG Ww5mBRV8oTC5JmfE+20/p3iwKtaqmmKK26XlJOUfUsMqrNbT3EgcFvuX2u3p0yx9W7IA 2KO7f8MrDDcE+XHalJ7L416z/YR/Qqg8CYEekow8qVxSTa3NTjOohfOJAnOp94N5X8VP iabw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721200754; x=1721805554; 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=ArgSkToA2nsjWvuTjSuyJoQaI0tJr7zvtfDgU/aUVoY=; b=YfxNGqL9dQdBN4f8PM8PhGSOwefWTsaaDCQzr17VpbzrPRDUHg7SnZckIn5OtOysMG LFRdc5jolFcnRHhCB4K/CFsRsz8hLrlRpboBxH4gvFIKhFcYiRZ4ZG+to6E09tDzbi5i S22DTI6HjE/7BcLbfWKH5kD1PIAGqsIaodHS+UyuChKhTMvJFPaDSb6O86kiK5gCX1sI uIEZM9OXNgv2BPSgqwXYxnHgpfWFKn/xenr4+gIORoQ9mzMsvUrx6CCs0r/pb+b/71VS rheeY61FhsMlzjxfqHvGQA8XSg73l28lhbx3lS0Byr+/dFSjALlvGJqpbNZOqjQ9Oxqe Sd9Q== X-Forwarded-Encrypted: i=1; AJvYcCXvMpPlhL2RY2WIO5dMmClv9yYoJNdKwhWWSZDzNdfnaXQqUS/qzPmhGwodIgReyvRkZhshVzd5L44sJAJ/IRguvRM= X-Gm-Message-State: AOJu0YzhwT0fjJWZF/Cg+nL4UDE6S/TyieIqv5qqcLVivI2vRvj1b9Cc nCk/GpQnwWg1O4cKccw1oy2noXFPBc1WPsiUWcKvycizalzx0jZh6wGSYLRKlSw= X-Google-Smtp-Source: AGHT+IEFiz1UoJ1wRFUr8yrOzP0AGE8hgSRnejnhyVKNJBJmgOedBuq6BWNoanv2GWM0dmVqE7bphw== X-Received: by 2002:a17:906:2b4b:b0:a77:cca9:b21c with SMTP id a640c23a62f3a-a7a011a1220mr45969466b.34.1721200753714; Wed, 17 Jul 2024 00:19:13 -0700 (PDT) Received: from localhost (109-81-86-75.rct.o2.cz. [109.81.86.75]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a79bc7f1e04sm413330566b.127.2024.07.17.00.19.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jul 2024 00:19:13 -0700 (PDT) Date: Wed, 17 Jul 2024 09:19:12 +0200 From: Michal Hocko To: "Kirill A. Shutemov" Cc: Andrew Morton , "Borislav Petkov (AMD)" , Mel Gorman , Vlastimil Babka , Tom Lendacky , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jianxiong Gao , stable@vger.kernel.org Subject: Re: [PATCH] mm: Fix endless reclaim on machines with unaccepted memory. Message-ID: References: <20240716130013.1997325-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240716130013.1997325-1-kirill.shutemov@linux.intel.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 59BC81A0009 X-Stat-Signature: nbgnsneh3ah1mgnm8qw4iodcr41zgtdu X-HE-Tag: 1721200755-65383 X-HE-Meta: U2FsdGVkX1+4Vhi1z1/60c/eWpOhuYyb9FOn2bmMY7c2vwqTzzNsxRn/YMTH9ORFOmKBxiPruwVxPksYc0eZf00hQCldL/R+cdHM8OnmxR7gnBaYDQfpHRD6nv0mp2tkmdznCnLgUGWQED2rqA4+CgWjg/PsXpiGsa/efC60Tw02588L4aTDRYMhkksOs3LyvuzmrzKcgPv5+c4hSrEIcw5kXuZUATdc7LkyyAzYcraApyZHy5Glpsi2qXzLrqKj90L2qfh9fr9Uq5hkJhliRlQFjDB/+C50HNphKw5/JCkdppx8Dd4ePbSvViqqvL7hPMxOhEWgB9ZCuc25OjoBggHQZK0QKUdr3tjospCbiU/f1Pu6Twfhk/GJB5Uv5qdfolA512qz1c0pGV4Rv0D6Qn8HLWK8/sqRg87We26o7MTl6mWTwXZDPOmvGQv4xAW2DKZrIOXOceid9Z+UFKBk424DsUD0mHNbffigdgzmp28ZxNJjYSDdZRh9AqOSy8NDS3AJCVmHeEYhobaUBmN5kE5C7L343rwa3yV8FCLbwdNN1Xb0SiT5M+2QnRA/IwmKPXezC2FgKAUq6SI4ARJaAI8SWKo1C85zDwQr3DXNGQRP+kzNc5Vf2ZIUjGqn9aydWQQ1+iFdmAGUw3IVFzL6c/83K/hPBfeY6VJRlFPAncRL1h0JjHPEVkhN1LKpLQkregkuF/0fOFrKUmmmwovaJdqWCiUAyf7y8c0UBbrtIRiwzm2k2DfqdlB3N6zWF7U4W4TrVXp1fWKu7Zrc3MJaPaUzIjOfZSyjwJizHW3W7wVsIdUChyU5S3E7JopcUW2WXRylCkqki4UNlY42L5i+G5i+PQGMuIxd62umkDSlASZIT4yXWKoqsblDWhooYVNmtcFDeBOdbbSfMi3V/T4HWPcWuu4RAco9hXo9/+jczDurALc8tR/tc+JErazG6E3gnta4qq4AxUhKRQZj/L4 wKIkmFtx oAnDFszgE4uNBB0dcy0YxzI74+vTV3+g/yWLwgxYgf/xEXfG8Dmhchzk4ZqgY1c89o25MG2yN7ipgNHr84edr59VGhf04NL3TpGI+kjKJ39KfkIxeb67noZcXXX/GWDuMHsddGYI6/4Mi9dP5ANh9CWStZj7Ktd9a7yvRBZqaPVqOTI90m+s8WQB+QIHNgln5PQPWotVerce/f8xqG0kaO0RUgpehK5wjpe/c/1QTZAP3L2yuH+aQ++/6vqm+JHtIqQAZcWHneYPGkkBHWsq9tyieypKD30AXp9GSUjpEqQfy99SFVVYx5KRfxyQdXV222CSXW6Mck6Tbc/IqmH9kKuk5TQNXgEVbQmgzEnQDNMGUIpJbrtwABmHR8XV8zq6pvHaYLwF9yvx4zqM= 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: List-Subscribe: List-Unsubscribe: On Tue 16-07-24 16:00:13, Kirill A. Shutemov wrote: > Unaccepted memory is considered unusable free memory, which is not > counted as free on the zone watermark check. This causes > get_page_from_freelist() to accept more memory to hit the high > watermark, but it creates problems in the reclaim path. > > The reclaim path encounters a failed zone watermark check and attempts > to reclaim memory. This is usually successful, but if there is little or > no reclaimable memory, it can result in endless reclaim with little to > no progress. This can occur early in the boot process, just after start > of the init process when the only reclaimable memory is the page cache > of the init executable and its libraries. How does this happen when try_to_accept_memory is the first thing to do when wmark check fails in the allocation path? Could you describe what was the initial configuration of the system? How much of the unaccepted memory was there to trigger this? > To address this issue, teach shrink_node() and shrink_zones() to accept > memory before attempting to reclaim. > > Signed-off-by: Kirill A. Shutemov > Reported-by: Jianxiong Gao > Fixes: dcdfdd40fa82 ("mm: Add support for unaccepted memory") > Cc: stable@vger.kernel.org # v6.5+ [...] > static void shrink_node(pg_data_t *pgdat, struct scan_control *sc) > { > unsigned long nr_reclaimed, nr_scanned, nr_node_reclaimed; > struct lruvec *target_lruvec; > bool reclaimable = false; > > + /* Try to accept memory before going for reclaim */ > + if (node_try_to_accept_memory(pgdat, sc)) { > + if (!should_continue_reclaim(pgdat, 0, sc)) > + return; > + } > + This would need an exemption from the memcg reclaim. > if (lru_gen_enabled() && root_reclaim(sc)) { > lru_gen_shrink_node(pgdat, sc); > return; -- Michal Hocko SUSE Labs