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 76FACC3DA4A for ; Thu, 22 Aug 2024 07:54:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E12A88001B; Thu, 22 Aug 2024 03:54:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9C7180017; Thu, 22 Aug 2024 03:54:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEE298001B; Thu, 22 Aug 2024 03:54:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9C22080017 for ; Thu, 22 Aug 2024 03:54:45 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3A7AE1C45B9 for ; Thu, 22 Aug 2024 07:54:45 +0000 (UTC) X-FDA: 82479119730.21.71BCCAE Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf03.hostedemail.com (Postfix) with ESMTP id 3BFAA20005 for ; Thu, 22 Aug 2024 07:54:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aAiNiVoc; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724313242; a=rsa-sha256; cv=none; b=SrD9+jXET0tZ2nzwOHb+KyAtr/7Fg5gEe/I2UG+QeGZTuQuAfTsCyljk/tHe7WJ1Cqghoe JYRBdCTfz6pCaR1S1OLJpaDmU5QiM424Fyqz0PUWtMCJv4SN4sLn/g+kyRQx7D3TD3hqmE mX6v4VVIIGMry4fZQ294pvaLtGOwqeQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aAiNiVoc; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.43 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=1724313242; 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=h/dMpJsKzCty7PyozAjDXVmfBlGRovYP8Y1Bj5uwLJ0=; b=wq5+RTlLD3xQQKUeWgQM3WtTW9Crueyfc0DLZPo3N78yzjhzmAOtomy2l4zJrzjkAIhlVq RYixCMb0Yy7HEmVTrm1T/HM99upPeF+2TsO3Iam49m2IHH619QzHNw2lojKe1nMkmBsIPx SdDP7qOYUV76SKgFFL76mJrKBF/qi2Q= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5bf068aebe5so829193a12.0 for ; Thu, 22 Aug 2024 00:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724313281; x=1724918081; 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=h/dMpJsKzCty7PyozAjDXVmfBlGRovYP8Y1Bj5uwLJ0=; b=aAiNiVocuNre4zuUNpCwoeZTF1OXrbLWNy6OVSkI/vDCmT5NH4zXO+R2S2EsMeUJO5 i5yo9QYO+ROOPpvEPiw4bc12v3KFNF6nBOASgQDrg+CCIUdAA5wqiOOS60wx7y99xmIK 2EnnoQw6g9fqknzpjAgvygoNeeimme1fgK6rIcAO1x85g3EPXvHnQAVElVCONo91okM2 KS1GnfkVR+Xl/dMdieZIzrvldGEI7HJWHhbdG/VV8yTydROejaDxxMOTxH/w+65hSYEP +sokF2gxNWizKsd4VfXiPieL8ZPCy/hlN+lAyTdHU/bSdXUXjRxiRNJVkaHWaMZPURXo Aiyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724313281; x=1724918081; 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=h/dMpJsKzCty7PyozAjDXVmfBlGRovYP8Y1Bj5uwLJ0=; b=iuL5nOW4FACxEGFHXnaXUE61CGEvQ6A8LEb+hB7U7xaCPJD+auVXMLHTr9xo/Nzhic 1yV9dg4hvOE7KXQ5gAI9E/k0yK4pr0ePnJHPoqLtR+Kx95oZdHNdWutctPsd0Wr12DbD paU/i1JTXUCF+OLvW2L7/AWz+DuqL3/78GwCc0htyeAZ4nQXjYemVK3QsHptOk6NFDmq fiKeskIajwqj+73rcpGY5f2NOQKBEXYD31a83VFFv2yXBgWdMhXxdv9k5crWprdH8RqH BHZfl6jF+KqmdrwWI6BGoFPbHjUWxEysAPhWLf7dam8Nre8gyQ3/c85//4Ld6CEB3Cxp EtcQ== X-Forwarded-Encrypted: i=1; AJvYcCWZFiyaRCuRNA7LJggkGQCO/xdQocagmREk8n5yuqd00sCoxNO1p53fyPQ7zMGNKyh8PHOyQ7pL/Q==@kvack.org X-Gm-Message-State: AOJu0YxSnLmI+Adpz6/if7p71lqyRPRrK4zJuE0guNKoyu+5aZC72AH7 tT2OQMvY+lyHFjjUNG36dtF45y/xuXyBjwBpVekKN+U2ThmKUzsauy87aKWJwJM= X-Google-Smtp-Source: AGHT+IGq4R4GrxX7o9hFe7kKdnmxkeZ7NThxzG6CVbaJLbEsy1IDahxB33tMpj6vYTZfwwfSA1NLAQ== X-Received: by 2002:a05:6402:458e:b0:5be:db8a:7f5e with SMTP id 4fb4d7f45d1cf-5bf1f282963mr2279193a12.37.1724313281414; Thu, 22 Aug 2024 00:54:41 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c0515a9469sm555414a12.92.2024.08.22.00.54.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 00:54:41 -0700 (PDT) Date: Thu, 22 Aug 2024 09:54:40 +0200 From: Michal Hocko To: Gao Xiang Cc: Linus Torvalds , Yafang Shao , David Hildenbrand , Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation Message-ID: References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> <9fa8eca0-ad4e-445c-a21e-aaabb6aa4160@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fa8eca0-ad4e-445c-a21e-aaabb6aa4160@linux.alibaba.com> X-Stat-Signature: qsrqu7bmeushg1o7qhndcdm5ryrt1q7s X-Rspamd-Queue-Id: 3BFAA20005 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724313282-774704 X-HE-Meta: U2FsdGVkX19p6Z18rJPPvmtx4FfC2QFtFgIIt45m3MBWjnDhiXDZpm2hrHVfh5qYRCGqoJM/0Ff0rOEiomhOv8XITNeyUR6UDqHvBR+3hmfGUsMAwf5VezEKq6gnUOB8Yjcmy2H9yO44JKn/arMQ0oStuymgHmkCQa/nLatyXPqJbsS6Fxa/6KbRA6+tzMh4o8Vdu9jXWRB5cVg5F/gZRxXg32iLqYJEw9fMby50te2B/exkIECoD7cR1GVvFczPYjJ3kt0/QoFIjSkpx3RfESuBs4iQk01El5q9BavfTVe6BMTvpJNkYKqPHEwVh48/rffcYGODPlZTgreCGi4iWwaNUjs8lKQkMZ6kg7mcgcezZd6CXplWjHjzBkDtyWCjP8nobXtcLbD+kLgv6GFJOa6Tza4AVItuo7+QRcMzNiu/xE8vmjp8rv9rNCJf3r0XhgBlbh7cQJdvJQu/5qzUpOtIJ/r2i8J+zW248MUkxI4mkRjEFw0O/K6BrTSBod5YBKPsKMAaqGH715HfFsul2bds67DxVvSxMMr+2LlI+chygXOuU8B78Ci7SFvnYBQVv8myLiia5N/V3TwAjPX00niATv5yNYw87D1+hhRdFGuzlQlU/gZZQs8Toyvk5x/GSLNxhkIiOlJd5XNrZ4P5OwPAnTgvLY/diGE6yv92+JDNZBSH8k6T/O3aFp1TAR/bW8AqwLL7M4Prccj8qt+blo5PV2pq13yBp2mFjoUKJUJtNvn+Uf1wYkrPMijqtUZrxM8d3hYNpkJRdAetL9TPUZBaUn07BTQ3XpL1Nh7U3ogHApI3PynHZESAQcagKQ4p6oxHX5+eAYsGprP700gt5cQLsghe2au7GdROBByLLwLO7Ia1sjKTLGyQ8ISqwHY+PajTerXkI7ClnmUh87uXsYBi02eE12OYaCV/21iGhCuPqYAXyLXC/DdoPrvNar1lBRBjEuJVCZW50QU3Wws Q0P9C4Tw iiHYv8DsJsKrS1N/8JakY0xQ92KDO4BbGyUAiPv5N7xiSAPIyzrG6YNejQPDAurJRvP87OCb8Xvsy3Jvnedz6YgyYog4IRqkfba7HkCcAbrtxpMYNSIQXX3x0ZsYPgRXyB/mg3TIsnBSm+a/7peGFPLsHo4hBOx2REBkEV4AU+vmapbfwpY09lVBLyvNyXMfTRDHWsx5leJi9MhqxiHxu/OuQqwZHncwbb0rSI1fxK8r2nTSoOu1HNhZQO98XuzOcYkjThw/TVbFf823lpXYEUbYLi5v0aumnCI9HvqHl3N/0kkAs9juxx83VqeQ6/9mFeBYHBmZsB1wrrToFQbpkOUVjDOSV6b+h1mwVOlo3ZQnY/Ug= 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 Thu 22-08-24 15:01:43, Gao Xiang wrote: > In my opinion, I'm not sure how PAGE_ALLOC_COSTLY_ORDER restriction > means for a single shot. Because assume even if you don't consider > a virtual consecutive buffer, people could also do > < PAGE_ALLOC_COSTLY_ORDER allocations multiple times to get almost > the same heavy workload to the whole system. And we also allow > direct/kswap reclaim here. Quite honestly I do not think that PAGE_ALLOC_COSTLY_ORDER constrain make sense outside of the page allocator proper. There is no reason why vmalloc NOFAIL should be constrained by that. Sure it should be contrained to some value but considering it is just a bunch of PAGE_SIZE allocation then the limit could be higher. I am not sure where the practical limit should be but anything that requires more than couple of MBs seems really excessive. And for PAGE_ALLOC_COSTLY_ORDER and NOFAIL at the page allocator level I would argue that we do not want to provide such a strong guarantee to anything order > 0. Just use kvmalloc for that purpose. Sure we practically never fail up to costly order but guaranteeing that is a different story. -- Michal Hocko SUSE Labs