From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933203AbcJZQcV (ORCPT ); Wed, 26 Oct 2016 12:32:21 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:33896 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754449AbcJZQcR (ORCPT ); Wed, 26 Oct 2016 12:32:17 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Wed, 26 Oct 2016 09:32:16 -0700 X-Google-Sender-Auth: 8bUSNudonvTq4h9lQfI17sPtnXk Message-ID: Subject: Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit To: Andy Lutomirski Cc: Andreas Gruenbacher , Peter Zijlstra , Andy Lutomirski , LKML , Bob Peterson , Steven Whitehouse , Mel Gorman , linux-mm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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