Received: by 10.192.165.148 with SMTP id m20csp2378026imm; Sun, 22 Apr 2018 06:05:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx49dIK5jLbDwtXKRDkcPwvlfT1vgM7vYe8QVWpUbKuSD3AvZ8umkMfer7sGXDeXWuD+fGS8m X-Received: by 10.99.126.78 with SMTP id o14mr4856009pgn.18.1524402341290; Sun, 22 Apr 2018 06:05:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524402341; cv=none; d=google.com; s=arc-20160816; b=CC9R+IWtZ7okf8k3dNm085D5bmvCdENU2u4NBsW+dI3MAzZ5ZWoufqQs0dFMSUi72F OypjrGHlx0OBs5w9EQ/QHdHgwM1Wk0E0DLim4HQ/UADt6ixkH2NjmByWbvizFPzGQxOL fSWZ2KNRZZok2BbMB4fNZioZ8BngZoWlXFpvnaJnplkUo1DghEn/p8QPQiXMbnLWYp7z zLsjc4PIs5Gbnanbo6+jPbdoeqf91Hjm9cvOdb93qCP89F7prlUKrn0j/8JTgIq3JQB6 fOWIW+bbYE/X1sTq0Ckeo9Zqahsq1KF2bwxp+xMCzYi5otwWG1t/yZ1GxEpyYYgxzwW/ /Ldg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=bLQXEyyNoyytKGfybhBvqrkGq252BzEk+ykivITzSkA=; b=XnfyzTV7z4/2vwU5VVkB7LzujuBa+rX8wWoea5uG61nBYWV0iL4bAlpciAtyiVu7o2 Wfgmn7PduV8u0ckBJWEbneaWYRlNxhqef2U/NtP7V/Ozu70oytcQTz1br4is3oIgaX6E bxhSbOpy+agmNoKsahmd08mrQLOnFKDFaGiFOnV/+/zYaM83zCFfVN50r4VAJKpcJ2uw 6KNjNzafaquq8jsYEz8IM5QsD/c9BRXd8a9alAtiukq5NR97sRF0E47/WromJ7RokA9h sLRcYMHNrxjTFOWgwcyoQWk1vavLq1fTAjCNSfM6N+SD0LBDGa1Oe3GWD8r2RGvDox9L dfNQ== 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 b1-v6si9632684plc.403.2018.04.22.06.05.20; Sun, 22 Apr 2018 06:05:41 -0700 (PDT) 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 S1751574AbeDVNEE (ORCPT + 99 others); Sun, 22 Apr 2018 09:04:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:53149 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053AbeDVNEC (ORCPT ); Sun, 22 Apr 2018 09:04:02 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2CCA9ABB4; Sun, 22 Apr 2018 13:04:00 +0000 (UTC) Date: Sun, 22 Apr 2018 07:03:56 -0600 From: Michal Hocko To: Matthew Wilcox Cc: Mikulas Patocka , David Miller , Andrew Morton , linux-mm@kvack.org, eric.dumazet@gmail.com, edumazet@google.com, bhutchings@solarflare.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, virtualization@lists.linux-foundation.org, dm-devel@redhat.com, Vlastimil Babka Subject: Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM Message-ID: <20180422130356.GG17484@dhcp22.suse.cz> References: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> <20180418.134651.2225112489265654270.davem@davemloft.net> <20180420130852.GC16083@dhcp22.suse.cz> <20180420210200.GH10788@bombadil.infradead.org> <20180421144757.GC14610@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180421144757.GC14610@bombadil.infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 21-04-18 07:47:57, Matthew Wilcox wrote: > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > > No way. This is just wrong! First of all, you will explode most likely > > > > > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > > > > > enabled quite often. > > > > > > > > You're an evil person who doesn't want to fix bugs. > > > > > > Steady on. There's no need for that. Michal isn't evil. Please > > > apologise. > > > > I see this attitude from Michal again and again. > > Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes > I agree with him, sometimes I don't. I think he genuinely wants the best > code in the kernel, and saying "No" is part of it. Exactly! We have a lot of legacy herritage and random semantic because we were too eager to merge stuff. I think it is time to stop that and think twice before merging someothing. If you call that evil then I am fine to be evil. > > He didn't want to fix vmalloc(GFP_NOIO) > > I don't remember that conversation, so I don't know whether I agree with > his reasoning or not. But we are supposed to be moving away from GFP_NOIO > towards marking regions with memalloc_noio_save() / restore. If you do > that, you won't need vmalloc(GFP_NOIO). It was basically to detect GFP_NOIO context _inside_ vmalloc and use the scope API to enforce it there. Does it solve potential problems? Yes it does. Does it solve any existing report, no I am not aware of any. Is it a good fix longterm? Absolutely no, because the scope API should be used _at the place_ where the scope starts rather than a random utility function. If we are going the easier way now, we will never teach users to use the API properly. And I am willing to risk to keep a broken code which we have for years rather than allow a random hack that will seemingly fix it. Btw. I was pretty much explicit with this reasoning when rejecting the patch. Do you still call that evil? > > he didn't want to fix alloc_pages sleeping when __GFP_NORETRY is used. > > The GFP flags are a mess, still. I do not remember that one but __GFP_NORETRY is _allowed_ to sleep. And yes I do _agree_ gfp flags are a mess which is really hard to get fixed because they are lacking a good design from the very beginning. Fixing some of those issues today is a completely PITA. > > So what should I say? Fix them and > > you won't be evil :-) > > No, you should reserve calling somebody evil for truly evil things. > > > (he could also fix the oom killer, so that it is triggered when > > free_memory+cache+free_swap goes beyond a threshold and not when you loop > > too long in the allocator) > > ... that also doesn't make somebody evil. And again, it is way much more easier to claim that something will get fixed when the reality is much more complicated. I've tried to explain those risks as well. > > I already said that we can change it from CONFIG_DEBUG_VM to > > CONFIG_DEBUG_SG - or to whatever other option you may want, just to make > > sure that it is enabled in distro debug kernels by default. > > Yes, and I think that's the right idea. So send a v2 and ignore the > replies that are clearly relating to an earlier version of the patch. > Not everybody reads every mail in the thread before responding to one they > find interesting. Yes, ideally, one would, but sometimes one doesn't. And look here. This is yet another ad-hoc idea. We have many users of kvmalloc which have no relation to SG, yet you are going to control their behavior by CONFIG_DEBUG_SG? No way! (yeah evil again) Really, we have a fault injection framework and this sounds like something to hook in there. -- Michal Hocko SUSE Labs