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 CDBDCC3DA7D for ; Tue, 3 Jan 2023 19:54:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72BC28E0003; Tue, 3 Jan 2023 14:54:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DC088E0001; Tue, 3 Jan 2023 14:54:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57DC48E0003; Tue, 3 Jan 2023 14:54:57 -0500 (EST) 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 492618E0001 for ; Tue, 3 Jan 2023 14:54:57 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0A4D91A0BAA for ; Tue, 3 Jan 2023 19:54:57 +0000 (UTC) X-FDA: 80314541034.15.19B3634 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf07.hostedemail.com (Postfix) with ESMTP id 4AD3A40017 for ; Tue, 3 Jan 2023 19:54:55 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EbYiDfIy; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672775695; 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=2Xug8HsBhB4vw61CYQrO6p56II484h234IA/MNnX9p8=; b=HtjKdCvQ1KpyjP5vi8n0hKdDg2clq6kklE10R38sdiA/xWFCnsi85pZzh/d+V26+oEAyXU FOF2ZDQrOFsDBdpcZ+4Gg88Pqu7nhKyzHh7ETE654eyx4k0QPxqEkD7xYWjbunuD6Dfmy9 H7z24CXs2of6rzpjmUiUfybCbpQv9bY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EbYiDfIy; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672775695; a=rsa-sha256; cv=none; b=X7XSy7jbt/7fU41mYmVJ6dZcIht8bIdhnKSPyLK1bJl7hee9nhI8TQfLRtJqn0s8vZH+eO XXljyuIXodUlgBaKoQuWvZnPEnAOJT8vE9dF87+7rqvNCXYnfzEFTDiGTsEG5BNXkjlfCG jJIILPnmyQg9e1TXiCMdOJiZMz9AACM= Received: by mail-qt1-f180.google.com with SMTP id x11so25380482qtv.13 for ; Tue, 03 Jan 2023 11:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2Xug8HsBhB4vw61CYQrO6p56II484h234IA/MNnX9p8=; b=EbYiDfIyp249xUh5FwvkVnPr7aBXtVFVGZSFtl9pIKq68SODoEw8kZPQnYL8sXX69z F8E5UHAWixIJOtaSy7hFVhbt6eKa4sXCG4zalB7Ox/hGl++YbRVBW/YzL9Wjbkm4SzAX YQKeVGr58BgkVk4yWdEMW4R74YCb6drskvcyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2Xug8HsBhB4vw61CYQrO6p56II484h234IA/MNnX9p8=; b=C2ua2ca0Cuy0Kx8yBiND8nj5+nYPxkQXeTUv2zsuyJXeLwtnnUzNWBiS7MFddz25Re S6gRfzJXoUPRimaYed7+HCWF3/p8TCWGQf6Kf+dg/9PgmWB87FFEy9i9Sb8ICSOhuEzz Gheu7IAXNRyywo1hAN6h0u+mDQdEQNQ/UAF+vmBm6y4UrErMMamKjk5GK/ArLP61Rj+A 47sm3h8864uXU6srBqN8hfGkzXhBQwMgKk0m3/LRllU2OsxjMHpVhKV2TYdHg7s5d7Zq na38id0cmFvAzeeF+1jRx+iXUDkzbi3GB0JvIyrPyfsYGc/CE9Bi1D4AOvfPSsQrPfgO abSA== X-Gm-Message-State: AFqh2ko5orl1zkDp45rm7cbzjgUelap7T0HA3/u+2b58YYIeJVM1cypt xb+ISh+U+qWjpLWaB1F3ouxpYX0f2CwkY1bg X-Google-Smtp-Source: AMrXdXsZT8NKcnCCb1ErMjlz0a3fSccGBBzeUWHJTnhWgl+/SI8fLZKDRhV/m8ycHTRJLdP5eIH5jg== X-Received: by 2002:a05:622a:2516:b0:3a9:70a2:2c59 with SMTP id cm22-20020a05622a251600b003a970a22c59mr69741378qtb.39.1672775693816; Tue, 03 Jan 2023 11:54:53 -0800 (PST) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com. [209.85.160.174]) by smtp.gmail.com with ESMTPSA id w13-20020ac8718d000000b003a7f9b48e35sm19040876qto.29.2023.01.03.11.54.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Jan 2023 11:54:52 -0800 (PST) Received: by mail-qt1-f174.google.com with SMTP id c11so25374353qtn.11 for ; Tue, 03 Jan 2023 11:54:52 -0800 (PST) X-Received: by 2002:ac8:4913:0:b0:3ab:88cb:97cb with SMTP id e19-20020ac84913000000b003ab88cb97cbmr986538qtq.436.1672775691842; Tue, 03 Jan 2023 11:54:51 -0800 (PST) MIME-Version: 1.0 References: <20230101162910.710293-1-Jason@zx2c4.com> <20230101162910.710293-3-Jason@zx2c4.com> In-Reply-To: From: Linus Torvalds Date: Tue, 3 Jan 2023 11:54:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings To: "Jason A. Donenfeld" Cc: Andy Lutomirski , Ingo Molnar , linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , "Carlos O'Donell" , Florian Weimer , Arnd Bergmann , Jann Horn , Christian Brauner , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4AD3A40017 X-Stat-Signature: sgyiyxatercg5hjxgkeuf5o5rr457j5t X-Rspam-User: X-HE-Tag: 1672775695-549427 X-HE-Meta: U2FsdGVkX1/mLeBGQntbnoF1yj79byQLRQhOsEPg08gYLJ8rIYRgABVAKI1N8qG1H2NVU4V9c8b8qtB73vUhEqOd2ALm1uRdZw+2QbAU0QU+eBAQgkVM1bPkoHoygSBe7pAay7MlfpieeVjjqwEfH/dSTJOyCAo5R7myO3VjwC0aacswImr5MSw/yXJ3Ol6u8xe9f293orqtJJv2nIN+WxzeA/Su1cMUpIBonb/9UD9yn5nQ8K/ea+6GKvGJ/tVPlpja4jmEM9gcP9caTW2iX2F9xFUGJYjZIEbixswOqR0beEnWls0NjBRtNg42e4+yLuctU8F8IO3H/CTox1wHOQcJOCRyvTblztUszQyjuUOxzIjYdApUEMQWNx6RU252H16cz5N0j4EOSCKhV/eqkLChn/ssGkpuHQlwAWD0MntY2KXB+79nc9aJ+meZCHxz4bsqDJL+gx2/pDi4LH4ziqJY/W9pM/G0hewCguWC4E7vK90CEst1k3ss7TFADst76wAPoJxSNC+NEN9MaW3HtcBK/Bg/gLaKxtEejXyreC2WN+nYYOK+aJexcUL179nFa5zidDXJA4NXb68TzSIYwoC+XeBhJKonKkl2QN2AhMzEZqkwDMmioKwfC/TLw61yez/UWpo2zeVlRvvYjOkqcMgvP2c+x1CXNhoYqpETHLpuieEX85tIiUFJ7XLUjd4yvtqhizrgE3RoECFneeolcehgQ0emHkUn71sx08cCvH3QEui3N2SSmsoLM2gMN1Tq0HnipsPD1hiQcxGV04VX0Du0bBw5307PexVwpg4hqKp6E/BtIfMbrad+nTb49eDkqa9iAJFpcVkuYXOoC0ummfJmbXHi2VHFIw8jz2w1Rg+z3wkGsay8A3vioefh3UX3pStSV6mUjSxX5NnUyhjNY20ov7Z4cVjTG69BIMNuDZxkrPwOIXJnXpdnYNzbRooEed4Lg9IAq45nG9pq1GU UKybvV4N xKlBB4RA6NPu5gjl3eISwZMQX7Zp6l6TVem9jSeXKcIwGA3XlgGweFBxW80/AJu1JBR7deQ3ajygsxZLFjpHRc9Bzn1rFFYXc0FbX5m+xfUF82bA1jyPKBKnUClmeIj2atPOkNJn+0SJiMbQcYJUjL0GDq+W2xDyzv3vrySFkRoFAR8BEZ96p4d1TzRtfSjn+dgEuZoxRUp/E6Bu9nPRCn9GmdXuhHsAv834oXZIRbeiO0AWd9vJeSqd0Y6cFKlGwdSNxSy+Lltlo6Ga0VScBnwzXG2pOTNxlHjSpFg9qUIFx4dCUEIl1l5Sn+PSj/OOHImikrSGdIKw5XGf2omh/5/ILEw== 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 Tue, Jan 3, 2023 at 11:35 AM Jason A. Donenfeld wrote: > > I don't think this is about micro-optimization. Rather, userspace RNGs > aren't really possible in a safe way at the moment. "Bah, humbug", to quote a modern-time philosopher. It's humbug simply because it makes two assumptions that aren't even valid: (a) that you have to do it in user space in the first place (b) that you care about the particular semantics that you are looking for The thing is, you can just do getrandom(). It's what people already do. Problem solved. The system call interface just isn't that expensive. Sure, the various spectre mitigations have screwed us over in a big way on various hardware, but even with that in mind system calls aren't some kind of insurmountable hazard. There are absolutely tons of system calls that are way more performance-critical than getrandom() has ever been. So 99% of the time, the solution really is just "getrandom()", generally with the usual buffering ("read more than you need, so that you don't do it all the time").\ Which is not at all different from all the other system calls like "read()" and friends. And that's entirely ignoring the fact that something like "read()" basically *has* to be a system call, because there are no alternatives (ok, mmap, but that's actually much slower, unless you're in it for the reuse-and/or-sparse-use situation). With random numbers, you have tons of other alternatives, including just hardware giving you the random numbers almost for free and you just using your own rng in user space entirely. And yes, some users might want to do things like periodic re-seeding, but we actually do have fast ways to check for periodic events in user space, ranging from entirely non-kernel things like rdtsc to actual vdso's for gettimeofday(). So when you say that this isn't about micro-optimizations, I really say "humbug". It's *clearly* about micro-optimization of an area that very few people care about, since the alternative is just our existing "getrandom()" that is not at all horribly slow. Let me guess: the people you talked to who were excited about this are mainly just library people? And they are excited about this not because they actually need the random numbers themselves, but because they just don't want to do the work. They want to get nice benchmark numbers, and push the onus of complexity onto somebody else? Because the people who actually *use* the random numbers and are *so* performance-critical about them already have their own per-thread buffers or what-not, and need to have them anyway because they write real applications that possibly work on other systems than Linux, but that *definitely* work on enterprise systems that won't even have this kind of new support for another several years even if we implemented it today. In fact, they probably are people inside of cloud vendors that are still running 4.x kernels on a large portion of their machines. Linus