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 0BEEBC5478C for ; Fri, 23 Feb 2024 22:01:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6982F6B0078; Fri, 23 Feb 2024 17:01:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 648666B007B; Fri, 23 Feb 2024 17:01:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 510916B007D; Fri, 23 Feb 2024 17:01:17 -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 3E8B36B0078 for ; Fri, 23 Feb 2024 17:01:17 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 11B141A120E for ; Fri, 23 Feb 2024 22:01:17 +0000 (UTC) X-FDA: 81824440194.09.57A9E18 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf30.hostedemail.com (Postfix) with ESMTP id 6FD4580003 for ; Fri, 23 Feb 2024 22:01:15 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zZaBS7s3; spf=pass (imf30.hostedemail.com: domain of pcc@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708725675; 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=YlM4WFBcw6HDt3SdyabOCqKS1eTxkglqPFWaiRtuTtY=; b=YHAhsvHWoyK9DjHJ0XYxU6cPT1UB5VjvkjKwOREtZd1rZGyLv9XtkTRZR7lYsUWQhfczni 1BdqrJuf8YDQ1yjxlUEAsb1WlXIQgKLUyBawXunCetVm6ayUu8KlUcEjUSHffidPZ4FbxX 8Y5+TE7JF9GgIBafBLb6OcA4PbpLbV0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708725675; a=rsa-sha256; cv=none; b=iF3pEHwRIR0+Nlv1qy73qobjuZmaqXo7DkspVly+PMkxtRsDI+/dL27hE2uOl+XYzbD30N VXoqyJLDtmcR5Wu5LQtnrOZPKndl6fXJyaHQcvo5vHbIU8/YpTLvmbpVPrI8jCyTj/DDZ+ 2kFoTeOo2BUwgjYRvzSR1Iqx69GO9Pk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zZaBS7s3; spf=pass (imf30.hostedemail.com: domain of pcc@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1d5ce88b51cso61235ad.0 for ; Fri, 23 Feb 2024 14:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708725674; x=1709330474; 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=YlM4WFBcw6HDt3SdyabOCqKS1eTxkglqPFWaiRtuTtY=; b=zZaBS7s3kLDRvAeDsXbSTqI2VbDOATcQc0AWQ6Cuzc0jntKMURdZXA4haEosoDf3l1 rlM37vV4t0exfdkK2rmDV6a9Pglhl9uZawZWRK54SXzj/K0H+rjQxzruVfSWbTXa3cxq pKJPfuWOTR8anFB1GMvBQzaFMWPMXJjzjGpU6Qpm1mCHM7+3vYZ0jaomKf6Vmm7zNCGu j/QogMf5NNJ9IyoeSU7cXOknWwlPa8J8u/v/jGV8E1sC7cIQQzhZnKpxyxDv50OiuSKx 9BlWv46ZXKAxwkqCGiL0BHhihx60wZi9beRlHmlUwbLWrY/sq2JNYAe/bTMSdj4ysh7V oxKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708725674; x=1709330474; 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=YlM4WFBcw6HDt3SdyabOCqKS1eTxkglqPFWaiRtuTtY=; b=NlJGbMTv/0EzWLVQ546mL4/AZYY+uhEfwUsopUrTWm8GBc/uqdX2qItMKMgE7sjHuD YKc32VNFWLTrFg35yOCYNH4G1oGLS9JOnkvhsF3aiKc1IgCKMzDAI3uXGnmcasjY86rb bcpjvKZI+EnJAUw2+7xKtuq+IeA9za4lmrYOzzpI3W/o5F9cA7QUHTDB+x+wkofQQbrw xwyeFz1uUsT8oOh+ScyqbPjovfYSr3JStiXGQw/N7tcYAj7i49WtRjVPbmluY5MckWeU ZAl9ToT2vffxkemqP4pS9xw5BqhbOm+a/PlE+oMsoBn6UWrwZzIulSqdBO1gZrn+A9YC kIkA== X-Forwarded-Encrypted: i=1; AJvYcCXzkuOl1mB1cN0qT1p24RrX7FSoTgNP5vnNkf8SFue4WWsEJDo/Ky3JoliNoKmwDzUeTdKv5cT+pblUvH2QmTK7htU= X-Gm-Message-State: AOJu0Ywxe2AaC0zciqGcl4GdfF1dSKDoM9KECb8+h64UmGQfj25jSK30 tGnOSt4DbYYKOHzPE5eOcA3kwraQlpjnT2ciMHB1f+NeKAKjV4MY94elmudayfxNYxPjET3zWv7 pjm8dGvUpAc8L+IF43jND+husFPwangB6WSxK X-Google-Smtp-Source: AGHT+IEn6LrXC5ULYL1QpegC3Q3c+5xnIM8wcjYm0janyottQJDcr2dps303MVgFxjRlj3POmlfr09ldvNTmH9g3fTY= X-Received: by 2002:a17:902:f74d:b0:1db:30fe:5198 with SMTP id g13-20020a170902f74d00b001db30fe5198mr73038plw.29.1708725673959; Fri, 23 Feb 2024 14:01:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Collingbourne Date: Fri, 23 Feb 2024 14:01:02 -0800 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks To: Matthew Wilcox Cc: Pasha Tatashin , Alexandru Elisei , David Hildenbrand , lsf-pc@lists.linux-foundation.org, "cc: linux-mm" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6FD4580003 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: hjhte1too19khg67yo8yaw7jp5pdh1f9 X-HE-Tag: 1708725675-8304 X-HE-Meta: U2FsdGVkX1/r7MMTupZcbBuIQ4l/ySziRr5Sow1Xt/OBMfHF7l5k25Vw7W1DU2Gv4Gv18Jeu86ZXvFlXs1+f9OB3NchTrEmv41n1ErXasdqUKCH3iPJ1kItIK3/CH9vy+qZCjpCAjFBze6l1TAeLicP8E6Mtj94P21NU7K5pKeV+/yZS2yYqVQyBwZWfP7GBEoUqsyf2+xIOjJ9kEPCxVIx9HaFM9EicjK9TGwB9bdFpSYfgYOPlVq3EcZsb2fHSy3CU823wE4XNnZln9yE627/vTlyMOzuwT/CCUhwVFnOqLsXt4qiGu4b8Q8R0z3GdlXbndfxsoiJ8difcd0qe2Q43+t9UC3L32r4ANRV4JnTFGZGHrTOPDAx9rOCy58pVMMBnPHcYpM537kKKXzCQxZyEFzC+zvOSemQICRo/nmEzyDGezDLvqjR+YVMPwcmEWA3f3GJrp58lZth4SVBF+hxZbuvtMpfv1GPsyh0z8JxFOLJaZ8CFzohPXFs7zFAIa0VayUx6PEGTg4hVYipgTHCa3P43MEUq+5z4aeBFmLW0VPppqVc1yL4GDHhrblpTeAKeDFQO8QJbvoe4ZxZSElVFNNGS7VMLiAFSDr9kOgUZWjhr4vCu7XDSgDDUwyZFPniuSJNLWvrAa6Daiu999xEQqygpy2jvXsK7Yrti+PmbiFkyHRD1nm/J4J/BFLyebOIo7fBXQQf5T6RKkeV6mvomOnge/f26IMY9Ia0cNGuO51lwkCP84IuXoPVpK+v+iglBNOw++wthOmZgH9gxbJYbgRsJZo/rnVq0WpQ+wwUvvapsXc+UGtzEXVQxB9445rx9XRP6Em45WjWmQmVl4LEywvHFgiMbW+LOTAoLuxh//RynQAOYwJh5bgeoi6wiwcQTgnzhZxEprn6geGxmsmW7BsTIiJaXC87MxOUO7mji0P3JBCbA4U7r73G+SXTYQjQdcnkGhH8U7hYfUeq s2g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001018, 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 1:56=E2=80=AFPM Matthew Wilcox wrote: > > 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. Okay, if it doesn't really need that many pages allocated upfront, that seems like the best approach to me as well. Peter