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 77726C3600C for ; Thu, 3 Apr 2025 08:59:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA873280007; Thu, 3 Apr 2025 04:59:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3116280005; Thu, 3 Apr 2025 04:59:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAB16280007; Thu, 3 Apr 2025 04:59:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A678B280005 for ; Thu, 3 Apr 2025 04:59:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 82A92AB41D for ; Thu, 3 Apr 2025 08:59:53 +0000 (UTC) X-FDA: 83292135066.22.E77FA72 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by imf28.hostedemail.com (Postfix) with ESMTP id 8F154C000C for ; Thu, 3 Apr 2025 08:59:51 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=VIsLXM5X; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.45 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743670791; 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=ICyC3s+pJ3fIMtUsu9o7pDmgGeOfPEFH4SmR3vdTuEY=; b=uVjRHXDLbCnCZ2mFZtXe553Rp1nrxi9eYQAYdqjFbgg7JhQdH1vKnlbkJGuj038Fm1OGVv alDwJ+rUJgVOON6Da7vFf9YmrA1IIOlV3jjzJe0McQjRWPfYWZlcLXjKbNgabnCCYkk68r DpzSYkAgbooJAVn29JyarVHITHKvSUU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743670791; a=rsa-sha256; cv=none; b=fnqKi6gDjKxDuG2hyHWEhUg+sFXym25N91e2MpaU43D8rj+NfkSaiqrayI4D0KduaH94eF rQcyYyfW9X3OQoc5OmlhEkBQVlKmIX2Nx7/GC9jJNwAcQTWClRJrpeWvlqtk6vzUUcyvod 3Uxqw9vyNw3jufYRBurvAg2Zlkh7apI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=VIsLXM5X; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.45 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-3913b539aabso351457f8f.2 for ; Thu, 03 Apr 2025 01:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1743670790; x=1744275590; 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=ICyC3s+pJ3fIMtUsu9o7pDmgGeOfPEFH4SmR3vdTuEY=; b=VIsLXM5XA+8hd+24PbyRPmrJVU/q36qXITcqhT5XAK3Y+JH/RKuO9oSFixrAl4I7vs IuDznjZBbKQykuJkvAonTPrqWVtuLmmMIrYOeYLE7dwKzsGg5LH/Cmcxa/OsJ3+r/DcU P2I0HCPhtrAJEE7UFMnqmFGkNKT4GlwOmKrHbOdwAQTJCA4zAxFhQlMX+6f0hSUkeoNS 1HmJute9HupxbpWz5Qi85k8WHHZwYgxNK1L3upXZvtz+UKHhzu0FPTPKiJ7dlx5CaaHr 4w1PzHtf0SARkAYsSBYk0dMLr/Od3IoNUR2S/bUtOJm9fe+ytgToyIfuJPNYlQMWcI+x Qw+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743670790; x=1744275590; 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=ICyC3s+pJ3fIMtUsu9o7pDmgGeOfPEFH4SmR3vdTuEY=; b=gT26lx7QaP6LSh/5mI61BPzBLkKiPBILV7ZVRr7Mswo1qEs9qIIHkqvTfddFX4LX+i vLC8K+FODj77kNoG3u3ATVcplFJfc7PE8GZEf1QCDOJZYEWBKncyuyw1/jEQLeBO9kw1 h43QC5D4X+acircD5HOYSet9XmFDpU9+gjzmbvChv4xuXaUnV5w6t9y516LguCJvKWy5 Rd56DiIq3dXQr6Z3WYWKl7Y4eSzwxbVQnRW2etPIjUef/sgPeVCf94886epA9pjz13V0 mEXvYru9MDtRuraYminFycIQSXdDfOaMVJfaQjE5kWF3ScMDxJfGYPFDZOccSJ/JIbaU SwDw== X-Forwarded-Encrypted: i=1; AJvYcCU/o4jRupxcahP+XauSXHfLACE0HacHM2NGwmo6N6lOKYZAhKvb7MNdQPy/50Kqu/jzWyKvZiveRA==@kvack.org X-Gm-Message-State: AOJu0YwbrokjuLLydjMqdiCeD5RzRvAXjNhvcVS8DgjQ9GsR+ai8fc8H N6fFkWR7JtCT/SW25Xoi+aCZB7PHdDpcqduX7acRlhH1zXuIEgC9onjlm+47v9I= X-Gm-Gg: ASbGnctbjz/z1BGMjMi8wtNbXkdxtLZ05SkZRjB9alvEvNi2ab9b32jLQKwfx3sU556 So1o1TODHZ+GODCJspRwQvy9PHDQSadP7z7yvctNWwERZYFUzBLMaIRA4/bIOJUJ9EESeyh6CuJ X15JUCiyQkHsphNQKOEWzzkq1ns2C7EDz1ZvH9AgezCKa49E9THKte9BcZePoPxSIoLxFp2HgaN rvYEQuzDKSzUa0updW1Dk4dvNUTNKYOw9vCUqVvpzb0qe+OwtMc6xM+s/SEjDVFFnMH3QaMGsR9 hjr+iemqcHzjw8bW+VM9jXJD8BXmHHESyTn5C4jYq1pnEnXfvJ+lcMU= X-Google-Smtp-Source: AGHT+IF6/cKhg/tRYLRyYy0gd6WLgBem2gk7vTyRY7tWsUc2r/1wFw8LOKnBmlJm7eilsE2eyynOmQ== X-Received: by 2002:adf:f40d:0:b0:391:49f6:dad4 with SMTP id ffacd0b85a97d-39c2f945f61mr1028102f8f.41.1743670789943; Thu, 03 Apr 2025 01:59:49 -0700 (PDT) Received: from localhost (109-81-82-69.rct.o2.cz. [109.81.82.69]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-39c30226dfesm1199443f8f.97.2025.04.03.01.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Apr 2025 01:59:49 -0700 (PDT) Date: Thu, 3 Apr 2025 10:59:48 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Shakeel Butt , Dave Chinner , Yafang Shao , Harry Yoo , Kees Cook , joel.granados@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik , linux-mm@kvack.org Subject: Re: [PATCH] mm: kvmalloc: make kmalloc fast path real fast path Message-ID: References: <20250401073046.51121-1-laoar.shao@gmail.com> <3315D21B-0772-4312-BCFB-402F408B0EF6@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8F154C000C X-Stat-Signature: fdrkgiexa3su6mgw49pjixtj13ke1buz X-Rspam-User: X-HE-Tag: 1743670791-714362 X-HE-Meta: U2FsdGVkX1/Lq3Ui4/n/G8RiQ4hq2T/oGspk6zVpEQk2iGDiEuIryO1amDWkP93ThTQ0GeWyUtNHCQHqtJLlydiuYkIRBtIweH7WSV5fPK+J7rb+brTR+ORwXm1jkFquwwC/q1MUPlT77XOSMpMXKRdxhJnLwHaa04IJi0uaRhf6PJ0tcP5KwfiKYFlerZ272F6J2Sdd4EoPjmQrLCU70SMUaMdDS5SYWBQzhmS9fr8jRINtgOEe5N8K7JtgHjyTvp11V5SBjQMhqE9bxUPUlKvAy+vh4IoWAgAKC45CpQt6C3n74fvUBNepD4E5qprXEOcZ4zeI3A9Ut8My0bJJUnZDKlCm8d2SoINmNyvR1QKXPJdH8nKA5dcf0CufCmvfj0N5/LzZkphIfv3Acn+9xFmzznma4qG6lxcOWOy4rsRop6YQUEWb5i1YI2tbCGYMziWIzsyDYuVMjiwGY2AKNFeWaf+wwaBVhPvb/tEoZd9t95qHpKjUC7nWgjp7BY1WLn23wqwgc+EVa3fgwJ9blmrRu7jOcusGQnYU6jf7gQnfdcN4IHJCeYXgF9UYTNr7FkUKQmSKMLnIyd3RCTx8U0ETDEXBw/FM0bTmTvsDcNnmRpy+/dEZpCjBI3MDvuGBGjIpZD5qHb0P7ve+XFRIQO4WBCwpELUNDfWW5u6GR6nVzetJIIpX3HXVTfPcOYm51JksfzlTqcKDST5Br9nlDymEyhBM1SzFRL3xBleWIBCA9f6VKknFHMUe57kqmVhkL2bWfSOMVadKaqmo43Q0nL5JKjgLe+phS4nwX//x7UNSh+xMXU3CwXDZ3HHEQlo6k8hg73xa10pI0csY3TlMzDryGuhrVVv+32xv9WicXtTR79OkqoVkL0bWPPSBuCCQop8Cm37oKsPmB/Cm6hAkBQQMdV+WkOCvC13bAIXhICbLkLijPpTcCrKq7w6OjymrwUGxDlLKED0LmAp0g50 h0M7c8T9 +zQ4vUR1fHxIZUzjNYii/r04frRi8ZoR3Tweucsp/CWaJ/K4mGAJHQoXXM062uncl239QnAFlrLdVIOp9OgwsWPK1ZmwV+wr2OC/sd2pFc0pTAHZ+RNIjDE1b/RaYbiG88IvhR1FCKX8u9vJFRZWK6D3Q+dxRLBL6SdXQc9WR+plS7dQxJWn+ZxNKu2dQUScZOcIAX9z9mg0i5WLGX/x2YF2B2nvtBPrlmcDubNd6ZO2bkx07kz3QzWih/5oqpz03I8Phlr3sOB6norMaRPbrNdJ4e6JXaHBE7MDdOqm9aAcG2R8TC8XA9UpJqLWOzq8o3acxds7qmQ6fQRwQIoF6WzE3HA4ue5QoCKNWiWIPxZCyJ5/AFbSMWoCO62PECc6ATzeh 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 03-04-25 10:24:56, Vlastimil Babka wrote: [...] > - to replace xlog_kvmalloc(), we need to deal with kvmalloc() passing > VM_ALLOW_HUGE_VMAP, so we don't end up with GFP_KERNEL huge allocation > anyway (in practice maybe it wouldn't happen because "size >= PMD_SIZE" > required for the huge vmalloc is never true for current xlog_kvmalloc() > users but dunno if we can rely on that). I would just make that its own patch. Ideally with some numbers showing there are code paths benefiting from the change. > Maybe it's a bad idea to use VM_ALLOW_HUGE_VMAP in kvmalloc() anyway? Since > we're in a vmalloc fallback which means the huge allocations failed anyway > for the kmalloc() part. Maybe there's some grey area where it makes sense, > with size much larger than PMD_SIZE, e.g. exceeding MAX_PAGE_ORDER where we > can't kmalloc() anyway so at least try to assemble the allocation from huge > vmalloc. Maybe tie it to such a size check, or require __GFP_RETRY_MAYFAIL > to activate VM_ALLOW_HUGE_VMAP? We didn't have that initially. 9becb6889130 ("kvmalloc: use vmalloc_huge for vmalloc allocations") has added it. I thought large allocations are very optimistic (ie. NOWAIT like) but that doesn't seem to be the case. As said above, I would just change that after we have any numbers to support the removal. > - we're still not addressing the original issue of high kcompactd activity, > but maybe the answer is that it needs to be investigated more (why deferred > compaction doesn't limit it) instead of trying to suppress it from kvmalloc() yes this seems like something that should be investigated on the compaction side. Thanks! -- Michal Hocko SUSE Labs