From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id DC9E76B0268 for ; Wed, 26 Oct 2016 12:32:17 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id e12so11935348oib.5 for ; Wed, 26 Oct 2016 09:32:17 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com. [2607:f8b0:4003:c06::22c]) by mx.google.com with ESMTPS id c58si2055933ote.227.2016.10.26.09.32.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 09:32:16 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id n202so24890281oig.3 for ; Wed, 26 Oct 2016 09:32:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Wed, 26 Oct 2016 09:32:16 -0700 Message-ID: Subject: Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Andreas Gruenbacher , Peter Zijlstra , Andy Lutomirski , LKML , Bob Peterson , Steven Whitehouse , Mel Gorman , linux-mm On Wed, Oct 26, 2016 at 8:51 AM, Andy Lutomirski wrote: >> >> I get the following BUG with 4.9-rc2, CONFIG_VMAP_STACK and >> CONFIG_DEBUG_VIRTUAL turned on: >> >> kernel BUG at arch/x86/mm/physaddr.c:26! > > const struct zone *zone = page_zone(virt_to_page(word)); > > If the stack is vmalloced, then you can't find the page's zone like > that. We could look it up the slow way (ick!), but maybe another > solution would be to do: Christ. It's that damn bit-wait craziness again with the idiotic zone lookup. I complained about it a couple of weeks ago for entirely unrelated reasons: it absolutely sucks donkey ass through a straw from a cache standpoint too. It makes the page_waitqueue() thing very expensive, to the point where it shows up as taking up 3% of CPU time on a real load., PeterZ had a patch that fixed most of the performance trouble because the page_waitqueue is actually never realistically contested, and by making the bit-waiting use *two* bits you can avoid the slow-path cost entirely. But here we have a totally different issue, namely that we want to wait on a virtual address. Quite frankly, I think the solution is to just rip out all the insane zone crap. The most important use (by far) for the bit-waitqueue is for the page locking, and with the "use a second bit to show contention", there is absolutely no reason to try to do some crazy per-zone thing. It's a slow-path that never matters, and rather than make things scale well, the only thing it does is to pretty much guarantee at least one extra cache miss. Adding MelG and the mm list to the cc (PeterZ was already there) here just for the heads up. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org