Received: by 10.223.185.116 with SMTP id b49csp2297110wrg; Thu, 22 Feb 2018 11:20:18 -0800 (PST) X-Google-Smtp-Source: AH8x225v0Hg3/hSnVPyR9tTsJGHKc0keqPxt/SBLOMPJYir+AYfxDpSrnpCJGJM0BhgeuwFOpkQn X-Received: by 10.99.117.6 with SMTP id q6mr6442459pgc.146.1519327218116; Thu, 22 Feb 2018 11:20:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519327218; cv=none; d=google.com; s=arc-20160816; b=GTiBE9+utp6vRJwfDeg3AyF9mvg+f2Vu2JdNr41Wp9HjhatGc3N54GSS/GAZVL+Erb XAuEgcdUwt6ryz4zWY8nbOspxXy9gb0eBGJhBFIPv0+SNbPbQbr5d8mrnBYKwC+Uioz8 iO+31gqzHGJi/t+FC8mX4AOScanE5YKf05zT7FqPyEIDkxzWrpNys/Z+i/UiuX5GChgj 0T5PyC+zpcMMAfymXq70YRtwN8nHpUDd0EscOwH/aZtcpHZP1sgRcQ1seIMcg/+9aquL NHiPpHhc6Dk0KHPa32Zz4I/b4iX0hNJFRcGPZNCpBFGUJMdwzHxjEup0NRRp17u8LAqO VtFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=A7dAJLlVLRfS3YtMm7eq4unNpG82aVHuo1iY3KHplCs=; b=xUxhGs2RSwM/9lD3cDUj9vKNvwsBKZh+iijTG5AnSF/LpnL1q+osdPpMYJ8Rt48w8E ZuoemBXpDe11+ZHeKXu5jijN8IIAdJcNbx97P5MboLvns+CCEh+pUSN1qghv5KezTUJU FsXl5Jxc78YEdTlu8fxRSDcJ1qjlUt/blWlxNkutZPG7EdRrVfOx2f3/WLNK4wEKJ6Mo ch1XtTvHZB6sUM3vLu9ARl81aKJsthpSgnlxtv6IzloEPk+FsiiqY+CczrkGH/7bd2yJ zu76hNh7mwS5fFzV11H6Wg1jOJeZJ1L5cOhB5kLcBtgFmb+Qu6jdgFMY3VK1pGvEv9po 36qw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1si393938pgp.637.2018.02.22.11.20.03; Thu, 22 Feb 2018 11:20:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751368AbeBVTTO (ORCPT + 99 others); Thu, 22 Feb 2018 14:19:14 -0500 Received: from mga01.intel.com ([192.55.52.88]:15313 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750816AbeBVTTN (ORCPT ); Thu, 22 Feb 2018 14:19:13 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 11:19:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,378,1515484800"; d="scan'208";a="19690022" Received: from lkannan-mobl3.amr.corp.intel.com (HELO [10.254.100.148]) ([10.254.100.148]) by fmsmga008.fm.intel.com with ESMTP; 22 Feb 2018 11:19:10 -0800 Subject: Re: Use higher-order pages in vmalloc To: Andy Lutomirski , Michal Hocko References: <151670492223.658225.4605377710524021456.stgit@buzz> <151670493255.658225.2881484505285363395.stgit@buzz> <20180221154214.GA4167@bombadil.infradead.org> <20180221170129.GB27687@bombadil.infradead.org> <20180222065943.GA30681@dhcp22.suse.cz> <20180222122254.GA22703@bombadil.infradead.org> <20180222133643.GJ30681@dhcp22.suse.cz> Cc: Matthew Wilcox , Konstantin Khlebnikov , LKML , Christoph Hellwig , Linux-MM , Andrew Morton , "Kirill A. Shutemov" From: Dave Hansen Message-ID: Date: Thu, 22 Feb 2018 11:19:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2018 11:01 AM, Andy Lutomirski wrote: > On x86, if you shoot down the PTE for the current stack, you're dead. *If* we were to go do this insanity for vmalloc()'d memory, we could probably limit it to kswapd, and also make sure that kernel threads don't get vmalloc()'d stacks or that we mark them in a way to say we never muck with them.