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 DAF56C5478C for ; Fri, 23 Feb 2024 21:56:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 423056B0078; Fri, 23 Feb 2024 16:56:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D3696B007B; Fri, 23 Feb 2024 16:56:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C1C86B007D; Fri, 23 Feb 2024 16:56:57 -0500 (EST) 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 1D4206B0078 for ; Fri, 23 Feb 2024 16:56:57 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D0C191601A6 for ; Fri, 23 Feb 2024 21:56:56 +0000 (UTC) X-FDA: 81824429232.06.4122E54 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id AA737140007 for ; Fri, 23 Feb 2024 21:56:52 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="C/4NXfI2"; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708725415; 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=2cPp8fsVsp4RUx/M5Fy33ww8hA5EA27SbVMNo0hMS3I=; b=Q77dtI6zjPhsFkgBys4bKuRa4iIsgtAm6jJqVVFMf3IG5yEPYk2vVMSowdfFSZa94ZXNF5 khimOS3HclltbmcYd2MnZX7AyZ6g2ywmBphqOwCoiaL2Z8alx+7WwdUtyuj9iLs6M9JOOf VwPEP/1YNof808U20OSy7SGyCAZwvCI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="C/4NXfI2"; dmarc=none; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708725415; a=rsa-sha256; cv=none; b=Dahus4n6JmJBVWtdN4j1GXElOUsoyJLv09rF0d0icl2Bqoz0b6Tl/gSwJL4WRzyJH+IZCY tJFkCI/uDZ5MQPa32m2GrKu+UJq0rug0HWmlW17ZdaI4FEOOOqfhELFJIkyrKrO8NBBXGF bkY3eIDs29+4KXcuT8K4O9vc6eH4Cak= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2cPp8fsVsp4RUx/M5Fy33ww8hA5EA27SbVMNo0hMS3I=; b=C/4NXfI2OblPuJUhyy0VqKUnbc t7VAzR9v4SQumMmuodzB2B97G/28Ev+KITJvde1qmk7A7bhl1OLpgJs/OomvvNn5DR53+v2mhjxeg F9C8/YQnckQV36kQ3NyyT/yJEVO7PQn9ElNOa8jj0mgyPfbuCYoBaXSBBfDQGtdMwyCyYX/ivKE4S /AsKKRAlpFKDAlAbUmiSILJNyBxHzOzkvBgySJamQoS4QuVJGIHrsvdhsukezXvFRebQRXpN2mTZr lVutwMNrP2hDIzcz76JZggGkoMsTi+dWKzmdO6T3Yb9Sg0QGdsBzguIIxQ6jcCuRNWKFRDEVH/Gql A8RxvN/w==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rddX8-00000008ZE4-1EIn; Fri, 23 Feb 2024 21:56:42 +0000 Date: Fri, 23 Feb 2024 21:56:42 +0000 From: Matthew Wilcox To: Peter Collingbourne Cc: Pasha Tatashin , Alexandru Elisei , David Hildenbrand , lsf-pc@lists.linux-foundation.org, "cc: linux-mm" Subject: Re: [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: AA737140007 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: hedupik4scwnwnsprcm7yj16b8brhdbo X-HE-Tag: 1708725412-591862 X-HE-Meta: U2FsdGVkX1/Rigu/f9tNEWXSz2sUmZJCU02NSvb8Gtoy8oDgR15MS5AFAX69YCim1zzr8daV6Ht1vsFFKXPxNnx9VBdpZhisuQPDZyOGmoXFsELvvHWibyriDAwf6TW5BVTOftH1VaGEvFk8sgNnnLYCElvwpJZG9HCJ+9x5nkcpzigSgS82iognAA+wWaZbv0+AyO8xFDt7DP2wLZO9S0biMcBrDyEV113zDEB/WkpG2n/hPBgbOfGio1AHo7m89U3D5mvZublouIiAtJW/hNlTI5FfD8gHfQPaPfwaCpUdT1+VJJHnO7txHqM9iSjw0XGGgA6b91UafPaQWYPzJXQWzwn5kliLLFV5gJLNvnGcJuFPONxmJ5QP/qGT5VqHFIZwS5gcp23/wgZ/k1UloBcK3taN305DATLIs8p6G5qIzDkNwSP5QXQuexrzBniFnbqARdNDnp3U0DKt5cEt6UMJpJSTCT3izbKvFNRi5sy8+c7fJfn1OXHDjY8X+DeO1v13LSTY2zJjUxKK+NdGzsSYlyigrVULqxvBgdCljX3XfgBtTq2xZk7sExxczIW7UYUeFlSlnSGEmnmxmpA8hLn4vZqJd7uzwsj6xRhfimnYDZJtE6rpwyN25i9mwDm+rnx19dxm1qcvjJizAvwJoMq67c/rx2QErg565czw50pFsh4mieZGcC+iMZMKKwL23M/AYj7XNIAgruPJ2oSdcD4IPU4qUvXM3WyEslAGB61GLQLOAgoNYNlxk9jAlwJ/76TDB0EZeVwn0XNXO1gIYBtEOTSrZk1QkMc4zikL/z4wZ8R2DBfEiUe9nUidJwDfEhzzUgGBHy4L+PgNWXJTdo+nu+1jZ1NFHeiAySWoblBQ/AvceHOViGX1uIxZYVYWqMe/9vZZqSBzRoPVdeFbj1aWNJZFilFQfB8gW9Eh5UysDuSmq1TebWPwvoOiFc3QyEg0QUl+9s5WZAxlEdJ xYnANdNR DBHar2YaTIrh4E43yZavBDhJcYGWgv/EPc6ISv4XxlVemSIzkfGTUvLoUmvsY/cY5CyBXrNO7FroDsW4iNWZPm81fjwArz077jtq8INmxPALgQUklsUGKIWz19nK1Z6wClEW3c5ke7my35RA= 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 Fri, Feb 23, 2024 at 01:49:08PM -0800, Peter Collingbourne wrote: > I wonder if this is another potential use case for bringing back > cleancache, as proposed in [1]? The idea would be that all kernel > stacks have 16KB allocations but only one page accessible and the rest > available as cleancache. We can handle a fault on one of those pages > by discarding the cleancache page and remapping it as r/w. That seems like the most complicated way to solve the problem. Stack pages which have not been accessed contain no data, so do not need swap or cleancache, they just need to be allocatable. And the fault handler needs to be able to handle faults from interrupt context, which I'm not sure all architectures can do. The "We need to be able to allocate memory from interrupt context" is really not that hard to handle; just keep three pages in a per-cpu array. Refill the array at return-to-process-context.