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 694D9C54734 for ; Tue, 27 Aug 2024 12:47:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF0FB6B007B; Tue, 27 Aug 2024 08:47:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D79FC6B0082; Tue, 27 Aug 2024 08:47:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF3896B0083; Tue, 27 Aug 2024 08:47:39 -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 9D2716B007B for ; Tue, 27 Aug 2024 08:47:39 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1DDA7A18D7 for ; Tue, 27 Aug 2024 12:47:39 +0000 (UTC) X-FDA: 82498001838.26.41F23E2 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf08.hostedemail.com (Postfix) with ESMTP id F1D6816001F for ; Tue, 27 Aug 2024 12:47:36 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="KA2ndYD/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724762793; a=rsa-sha256; cv=none; b=4LEuO4xomuup8Lxy2VdzWtT6KVhzraSMVM9xznUp+b7Xil+wReBBX7u7Xi3rtrsKVx5sWT d/po55WdK33waM3lB/V5l2wJTELLkXJH+OR0905D4F1ZCkwOOL1qcZFmP0DAmKoYe2/f1m EEzysPHklpeQmSEH6qbEDEMKyLqn7gw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="KA2ndYD/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724762793; 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=WTsY1OQvaQ96+WTh0hHjByyS4uHxvasMiB+TQotf8Dw=; b=Hvki4YJjdJgfSCo1KHnuQ2pRAJ3bLE86sZsooEky/CYkBPMZ32rodsHXi/nCg2LanJ0mcO rOTiTyEJS6HFWW0y5Fsk7icf0c92HH4ryWeqWQdcDVm1PZaTXSvbXXy18Bo219H6pfDr4h PQX3m0Bqz5R8n21Q3hN2a0xiU6HpLLE= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2f50966c478so23897041fa.1 for ; Tue, 27 Aug 2024 05:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724762855; x=1725367655; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=WTsY1OQvaQ96+WTh0hHjByyS4uHxvasMiB+TQotf8Dw=; b=KA2ndYD/Brj3EzgS7cbEy+EDqcnqzSX50vKq1E+dz5R/5kYLHPT3GB7MunMMk42IiI EnmFjBW0ZPm9APq7BLeXIU7V5Zi9KTjA3Sjif+bFZy14nLhiK14LwSp0ftvb8t42+Tue 7Q5vSC0ahYV/j59jRAqETzHR5QfiX/rgiPgRaMgnZuUwQEA4ZWPyLt0C4ew54Tp9qP2r anhQ9xDY+OTOfa8EFwoiL3XVkSkPPr4D4w7f7NBGwzjyinSYCRolrgDSxt8dFPjxkchx YjiK7+hQIMgLEt+/siYGY3vwEkY2MoGV9RkM1QDqtLqTvhS0fSloG7WGYfumZXW2CCVp IHnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724762855; x=1725367655; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WTsY1OQvaQ96+WTh0hHjByyS4uHxvasMiB+TQotf8Dw=; b=I3ZE/y58ug6iGLiJGIe8CMz775nk5N3DIwLrRwjJBKSS4psysaUBjGE390Pxvt8KtK hTckYKw8XcaoKJoqsL3Zp/X8YYvkEtkBmN2QBqsb2sS7bRM1AvVRSggCHY3Yj3YknLd/ KmIUmsXSikO4GSHlCpAdOpE3z0gknVxjJwXYt9gKnTluZPJNb561ibufJKPCh+88KWNA laMZfRwheg5ozC+aPzOr3GKyzgbEtf6yleJ+efcZdpFnHrGlhXk8vKtxt0YrYZ++ZAYi HqFRB7z5E/rjEDC/n9elkaEvH5CaSl0XSYJarSMU9mjk8odZy8tWnuzTKrNn97ioNPA5 5VQA== X-Forwarded-Encrypted: i=1; AJvYcCVYH9PNzJaKLj+fKoucoEOcmyN1W3Kkp1LHlMGOi863HRiLuDd65NZ/GboRxYH/KHq2P55wI1FjRg==@kvack.org X-Gm-Message-State: AOJu0YzF6dX/WZ9iMxqdXzTGF28XZ7YfFQlEF3ML+1/BHgNWF15/LfAx n3brrIDMj8OcXtyIRlHdLYZmgfc58DLaUK8KL67/bcQ+qaXXqqWf X-Google-Smtp-Source: AGHT+IFpmby8qEhRSQcb+/YF//pOeyUg9yGHuBr9W9k2QuOxSz9CDjC9ConH0eXNYDwRzCMuNXSLmA== X-Received: by 2002:a2e:4e11:0:b0:2ef:21b3:cdef with SMTP id 38308e7fff4ca-2f514a44caamr17878701fa.25.1724762854290; Tue, 27 Aug 2024 05:47:34 -0700 (PDT) Received: from pc636 (host-90-233-206-146.mobileonline.telia.com. [90.233.206.146]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f4047defaasm15320271fa.66.2024.08.27.05.47.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2024 05:47:33 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 27 Aug 2024 14:47:30 +0200 To: Michal Hocko Cc: Uladzislau Rezki , Hailong Liu , Andrew Morton , Barry Song <21cnbao@gmail.com>, Christoph Hellwig , Vlastimil Babka , Tangquan Zheng , stable@vger.kernel.org, Baoquan He , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 Message-ID: References: <20240815220709.47f66f200fd0a072777cc348@linux-foundation.org> <20240816091232.fsliktqgza5o5x6t@oppo.com> <20240816114626.jmhqh5ducbk7qeur@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F1D6816001F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3nh683muyym8khuek1s33rs3czd8hqm8 X-HE-Tag: 1724762856-647272 X-HE-Meta: U2FsdGVkX1/Qt5o6gbtU4vZLLEVJz4MTDBx2VjaafO3e3JxRnTKLBPtNykrBhvlvTMKXe6IdCT2c7RrY5t70Ehrfe4jTNeWueCbHTsp5LjhWZBTBhHgF8uuEodiWL5PkPLd7KhsyRWCEkjdpVwh3RGZWllsSpPxsqbMSYTZkWvJ+qfu0WfnwfBdqOy3Lb2NdM3oX5mtKn/5yoKxtqiz/TnMBBIgh7lAlD0Su8zq4GRpvHNKgB6WeJ+wJOTwQSH/2qcOvbxO5sP/dyPoYfX0HtocCk76fBSEqKM7O5tnQJ/7zJkNJtsFf/BoxzaXa+Gb7hRqwbzTTOYBXnMqA+gm6z7N/B8wQCPPv35cC4oGqk/dY+krvECXCO/K4HuQ58mKu1+AmvzvKiXWUb4HA8GN9FGH1vo6UsPzJc/zYivhJKRMEbZ/t/yLUKexILRtEVmDsqtLghpEzjeO+FQD5aVqeNAKoBlQLgdWgKZNrlG4IhiKLRkf1k7zC4VZrTC+fxWjUJ+ZRtrVdhpoNoAZk9Kxo2LlzsxFdYSjStkd0nSNHCmoRg+rXi2Wv39bgBbjM1mZWcI8igcdIi7p/jtO+HmsH61xzZQE0zuNbv/zFEJllCvrQ08jNj8DIRJC324ByqYUfQMmx04ytlm6qLCVj0OTM9BG+j9wFM2XXWlQy1DLSVfmxkejq8TZOD38Wygh0SM0zcxBtwlLjcernM2xT37jfCGl1S29FD7cIS0d98/kVDcjLIx64Z4/Eop+/ocR+0BcLYVHaDZIHjwMKfwjgVassLlgrc0nVgu4xqmUm4JqkBD/jmD9zPN/SBYKjXPDgbUZHFbllXaypan1jK7VDv0LPgxTUeveDstRdpmkUd9/7+wjSlCn3WjkQ5jVF7JyXAMBqbpVUIUk1GypGcZCGVu/vvKvTN9NaqyfMBWig7QCdG0igJf8gmpGfaoLCQxOz9lxImVeT35UAdmp8XN1a/Tv nfLtJDmd riiK6MiDAXfI14iBlLme3MW4mHs8Qf6GCr0e8QCVnLlyooI5LmqIvBUdtXc5SarKj74LneAC/wYIWkoRP1BUkEQ7B28KpGMpi+xMJw7KackO7wssnDwnQbzRnDTf6NbOV/Bkha4gSwJw9h3FP6PAF2EU5LxI/48DlmDfcz+KXrPzMsnVjokr+wJZt69a1ro4sKFPnVe/rARrLB5wrbw/wB0p75gDezmJr4SRTDvN1bi7QO9x415awxYPzrEuY74waGBMiyLGHO7zOXs5AL52gfGc2Aw0Ey28naEXS8BeyRHeCIEA29vcBffP1oZl74C4tI6YTfRTdbcrPXoOsLkt5uxrXwufKmAU0uAAmw8fqxlpETzACh5JQ9vaRNHjZK7xdsVUGv1lbP6kZILUNC6G04V1pbMog9VeMfiOP 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, Aug 27, 2024 at 08:49:35AM +0200, Michal Hocko wrote: > On Mon 26-08-24 14:38:40, Uladzislau Rezki wrote: > > On Mon, Aug 26, 2024 at 09:52:42AM +0200, Michal Hocko wrote: > > > On Fri 23-08-24 18:42:47, Uladzislau Rezki wrote: > > > [...] > > > > @@ -3666,7 +3655,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > > > > set_vm_area_page_order(area, page_shift - PAGE_SHIFT); > > > > page_order = vm_area_page_order(area); > > > > > > > > - area->nr_pages = vm_area_alloc_pages(gfp_mask | __GFP_NOWARN, > > > > + /* > > > > + * Higher order nofail allocations are really expensive and > > > > + * potentially dangerous (pre-mature OOM, disruptive reclaim > > > > + * and compaction etc. > > > > + * > > > > + * Please note, the __vmalloc_node_range_noprof() falls-back > > > > + * to order-0 pages if high-order attempt has been unsuccessful. > > > > + */ > > > > + area->nr_pages = vm_area_alloc_pages(page_order ? > > > > + gfp_mask &= ~__GFP_NOFAIL : gfp_mask | __GFP_NOWARN, > > > > node, page_order, nr_small_pages, area->pages); > > > > > > > > atomic_long_add(area->nr_pages, &nr_vmalloc_pages); > > > > > > > > > > > > Is that aligned with your wish? > > > > > > I am not a great fan of modifying gfp_mask inside the ternary operator > > > like that. It makes the code harder to read. Is there any actual reason > > > to simply drop GFP_NOFAIL unconditionally and rely do the NOFAIL > > > handling for all orders at the same place? > > > > > 1. So, for bulk we have below: > > > > /* gfp_t bulk_gfp = gfp & ~__GFP_NOFAIL; */ > > > > I am not sure if we need it but it says it does not support it which > > is not clear for me why we have to drop __GFP_NOFAIL for bulk(). There > > is a fallback to a single page allocator. If passing __GFP_NOFAIL does > > not trigger any warning or panic a system, then i do not follow why > > we drop that flag. > > > > Is that odd? > > I suspect this was a pre-caution more than anything. > OK, then i drop it. > > 2. High-order allocations. Do you think we should not care much about > > it when __GFP_NOFAIL is set? Same here, there is a fallback for order-0 > > if "high" fails, it is more likely NO_FAIL succeed for order-0. Thus > > keeping NOFAIL for high-order sounds like not a good approach to me. > > We should avoid high order allocations with GFP_NOFAIL at all cost. > What do you propose here? Fail such request? > > 3. "... at the same place?" > > Do you mean in the __vmalloc_node_range_noprof()? > > > > __vmalloc_node_range_noprof() > > -> __vmalloc_area_node(gfp_mask) > > -> vm_area_alloc_pages() > > > > if, so it is not straight forward, i.e. there is one more allocation: > > > > > > static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > > pgprot_t prot, unsigned int page_shift, > > int node) > > { > > ... > > /* Please note that the recursion is strictly bounded. */ > > if (array_size > PAGE_SIZE) { > > area->pages = __vmalloc_node_noprof(array_size, 1, nested_gfp, node, > > area->caller); > > } else { > > area->pages = kmalloc_node_noprof(array_size, nested_gfp, node); > > } > > ... > > } > > > > > > whereas it is easier to do it inside of the __vmalloc_area_node(). > > Right. The allocation path is quite convoluted here. If it is just too > much of a hassle to implement NOFAIL at a single place then we should > aim at reducing that. Having that at 3 different layers is just begging > for inconsistences. > Hard to not agree :) -- Uladzislau Rezki