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 6FE5DC5475B for ; Wed, 6 Mar 2024 22:13:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A23856B009A; Wed, 6 Mar 2024 17:13:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D3C06B009B; Wed, 6 Mar 2024 17:13:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89AE76B009C; Wed, 6 Mar 2024 17:13:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7AC986B009A for ; Wed, 6 Mar 2024 17:13:09 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4660714035E for ; Wed, 6 Mar 2024 22:13:09 +0000 (UTC) X-FDA: 81868015698.27.8AD0FE0 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by imf21.hostedemail.com (Postfix) with ESMTP id 7227A1C0017 for ; Wed, 6 Mar 2024 22:13:07 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lfRmkcBT; spf=pass (imf21.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709763187; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0co437MWlwiDr7sdvNxT0czQBG4oFsy/9/ksjHplhkY=; b=O/YBVrjxCRJLXOP52ROW0VUB7vdNn3Ec0lr0DVjpxa89Ozc6ExGp9F12+pSN2gSGjkFW+m IbwukJZxuKxpKw5CA344n70pVr73DEGlHt2WAlv7tcbUAxTot9ovAGsS88S1Mnhhr0GZMU W6UBnKTg9TQErp0J5d/oE3rGh/2eEws= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709763187; a=rsa-sha256; cv=none; b=nzmCSKlmWWCrFHcrD87szOlLOEBgQHJ5oaxrLTOM9BoLitie7NAFTaO8K77tX2khfko1Nf Rj2/1FwsNjg1p07vX1UpfUyY76fLQ7Z4YvFKaBrMAwiy+LnggMyHoDXVLfQz9LTS4JgrrU n4B0wfPfNIO3dlpzbgSvDAcoBBcM9nM= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lfRmkcBT; spf=pass (imf21.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-412fc5f5099so2074915e9.2 for ; Wed, 06 Mar 2024 14:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709763186; x=1710367986; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0co437MWlwiDr7sdvNxT0czQBG4oFsy/9/ksjHplhkY=; b=lfRmkcBT3fp5wM51vdeLIXT0tCtMnWTkhPVqJU4vrgT6Q3Fca6wX3SqhcdzQvkuMm+ p7yuPD51GB7IbpBJPEUz0ilI/5ZenawYtLqsIPjAKvJnMYlrM2b7F+RJh+0sa23PhANb 2vKrhi/ClqdVQsQRoaTlsviLVLb9zxTXkkiyYATwoO+tbFuP2bq8wqRW/HNE9JrcBxz5 StMPhNBLvSxhDudi3gttPmQUSnaYGo6cbqDpw8aN3zxUp9Vq3p+JRZV5XSzl/a8zKKwb rkSwfSagaetjQvM7myeXkDn2dGTSasOU0x0fXnBRcT19hJBTJc/uaMGuj8BezS9bT17y Ty4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709763186; x=1710367986; h=content-transfer-encoding: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=0co437MWlwiDr7sdvNxT0czQBG4oFsy/9/ksjHplhkY=; b=kwffRE29SneAmJr4VEmVDzhRgCweXBM+OamnULYhui48LczWRZEeoqIBdvS4yNzfvd u9FiUoeHDx5P6yBP+DSUT6XKF41hJ0QmC88+AT6kJ1Qx2IXzDvWfLXXvNpFEmKG+l/vZ +WFKLUtoe6gICImIXshZVwI9DEPNWSUrTmgrtyBHrcobAUs16xVTYxYxW2YAmF92T6nS gtdzCBkq9RM2AampLPGJjCH4TunR22de25LpMN5YqIsdkDSAdyyrEgWAIJJjOJdOf72G d/SpPg/tdoCCcRxD7PN8dd80kPQvq8Gwd759xi86mKbM33HrurJ7rdN8r28Y+pc908Av bkaA== X-Forwarded-Encrypted: i=1; AJvYcCWF1de1Lf8NEQ59PpBbIuxyn/PiFpA1SQX3wgT96Gzqg880NluV6+WgowmdR/HY659CejAHrI16S62kBGgUYYmoshk= X-Gm-Message-State: AOJu0YyE/2JiIH6JJ5l9XV9xX+GEDzanXVowOI9hnOJFvIUh4zVXEVhF JVJicsz2gQcfaACaS+7P+peqV7dH5zEg3n37jGt3kDIPiSKHD/mvoOm+zBrC4pVP4DGcYIDWSwt scVS/Gs+vE8Z1RWZvUhgogxr2F4o= X-Google-Smtp-Source: AGHT+IHM5WAdyGr/B7hLl36s77xYo/gy7yzLMW3COR6pSamXxzxHTbpB4M1O/zLuG0Dc6UyW1yEJEoYoydHCAh4AHuk= X-Received: by 2002:a05:6000:1cd2:b0:33d:82c1:f9d3 with SMTP id bf18-20020a0560001cd200b0033d82c1f9d3mr11649861wrb.4.1709763185840; Wed, 06 Mar 2024 14:13:05 -0800 (PST) MIME-Version: 1.0 References: <20240305030516.41519-1-alexei.starovoitov@gmail.com> <20240305030516.41519-3-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Mar 2024 14:12:54 -0800 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). To: Pasha Tatashin Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Mike Rapoport , Boris Ostrovsky , sstabellini@kernel.org, Juergen Gross , linux-mm , xen-devel@lists.xenproject.org, Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: js39bgquydpdzxk7hgp7soh1s867qaxn X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7227A1C0017 X-Rspam-User: X-HE-Tag: 1709763187-888596 X-HE-Meta: U2FsdGVkX1+21EbdZW6SSWlHxoce3k+IkHBSJf4FqWHOnwZU6qvHe0mNd5cjQbTJFeIvZsSFeJMVmz5yZ3KxiCBxXzjJfDydJc/pbQR8e5PbD12EwLgB9ZCRqCl4ULZ29AoKs0kxLNSQGOY2zO69V04YcL7xeHQpJl8qx2Yu6etHSOKhaLPRQsbdWR/Rvr8yZqn2iQCH4F4LxSLGeE7+dQVlechQbSthzwvKJ9jLG/2lCnWROyR1e1Wlilnssf26lj1VHz4WqJroO5F1bWDYcEQibY2pyyIOzGEpTuavTSxguTbgLnyUbcFtoBcMMxHM93u4U03+fBRpdxq42vJsENedAj5w7sSOeuLPF6JMfstzk2/c8gje59hQrQiS0U3YgbY/pi0b1va0t2ENBmOW5DzzddP2UNo+oYDPFdkyEWCBEzhmiVsdZfYT8rsPbujcXxwRxrRWVWB5xj/Hqe2wp5ns1W7Ig0ijF2m3Zxi8pLW7/+Yj6PhPgjXdkZCoYzbqgM2U7evELYrfy4WNNaaRbmTjhZ3ZveBCW3eQnDECMBPJgkCNw0I3fGbCFOIF3gx1Sw9NxizEgSXiBfG7Rh8oNgt+4JcuPRr0uHvcKyTwlcXq7RUE46gaGLFlMQacLrLSzDG+/PUzO3jJAlAZC35grmONxbVN88NtxJK/szPS+ZiTTmttMvih7X5aqc9Pgr79aHa7bIMmlUmTDiN0qFqNWYT4eQ9Jo3pCUKX5OeftGqIgSl65xtD1ajAsE8bFaKRvOzxUQvN000f+xCIObDGC8wfIMspKCw/L8LZ1Yd4QAZmowqotx3ayoi2C0rx/u0fs0IXr5pDzc9Tc26Tf8uiCyw49zlV0ueoxjgFtebdzDnG3g2a+PxHBkyWhd0UUZTEtSmGytGBm2nryhHfCPOqu0/txK22NJCuie4+DdAcdnhK/v/kUhWXOiTgzKHqeAxik4xfO0PHOK1EdkbE7+W0 L+glnN7J CS+Od77UGPv+OZarlgwI8PMOIsVISrVTTNRE+JNpoPu+MHMSy2qvQQDXTRaO77kXoRjfEYuHX4TiOrs3AFGKTFKvWp0vl38n7OyG+ePLfM0daJLuSBQQ8Oce/cMwFaP+Fvn1poi41jMRPORMFbcarbtoauVdmemTxNBVy3gKGBFu/am55tTzWrTbUySxYdkjQPFO3UPHM721dO5XM9y6JYKgDJ510/335h+OdLZiUHW82rMrRJou50IJXykdjvWYE54Re5EFk6RxneWkvFzJjXVoWr9V7lPSljifaFwWTCAlhVkWxR+xFq4nSoIhxJLHkcJG7tk20grj67ekhP4uAoYlk/MB5hkopgQE6p3B9VPTvnJRJ6qkY72sZUta7mhDD5rfckJABmZYVJSGJUMOfnbIptv7/CxuClMxX8oSKNk49R0QrGt11liEG8Fs2EUQA2u2JIqyTcjLcznMKac8DlUtAWH4E4nuXG9Q16uHW6IyAoHgJv4A8vcB9vvw/RZJse5C7UkSj/uyWKQLpzN6co2XJZNNtfL3qYMWcSgMPB8oCHNA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000031, 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 Wed, Mar 6, 2024 at 1:46=E2=80=AFPM Pasha Tatashin wrote: > > > > This interface and in general VM_SPARSE would be useful for > > > dynamically grown kernel stacks [1]. However, the might_sleep() here > > > would be a problem. We would need to be able to handle > > > vm_area_map_pages() from interrupt disabled context therefore no > > > sleeping. The caller would need to guarantee that the page tables are > > > pre-allocated before the mapping. > > > > Sounds like we'd need to differentiate two kinds of sparse regions. > > One that is really sparse where page tables are not populated (bpf use = case) > > and another where only the pte level might be empty. > > Only the latter one will be usable for such auto-grow stacks. > > > > Months back I played with this idea: > > https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?&id= =3Dce63949a879f2f26c1c1834303e6dfbfb79d1fbd > > that > > "Make vmap_pages_range() allocate page tables down to the last (PTE) le= vel." > > Essentially pass NULL instead of 'pages' into vmap_pages_range() > > and it will populate all levels except the last. > > Yes, this is what is needed, however, it can be a little simpler with > kernel stacks: > given that the first page in the vm_area is mapped when stack is first > allocated, and that the VA range is aligned to 16K, we actually are > guaranteed to have all page table levels down to pte pre-allocated > during that initial mapping. Therefore, we do not need to worry about > allocating them later during PFs. Ahh. Found: stack =3D __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, ... > > Then the page fault handler can service a fault in auto-growing stack > > area if it has a page stashed in some per-cpu free list. > > I suspect this is something you might need for > > "16k stack that is populated on fault", > > plus a free list of 3 pages per-cpu, > > and set_pte_at() in pf handler. > > Yes, what you described is exactly what I am working on: using 3-pages > per-cpu to handle kstack page faults. The only thing that is missing > is that I would like to have the ability to call a non-sleeping > version of vm_area_map_pages(). vm_area_map_pages() cannot be non-sleepable, since the [start, end) range will dictate whether mid level allocs and locks are needed. Instead in alloc_thread_stack_node() you'd need a flavor of get_vm_area() that can align the range to THREAD_ALIGN. Then immediately call _sleepable_ vm_area_map_pages() to populate the first page and later set_pte_at() the other pages on demand from the fault handler.