From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755700AbeDWPP4 (ORCPT ); Mon, 23 Apr 2018 11:15:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:47842 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755047AbeDWPPv (ORCPT ); Mon, 23 Apr 2018 11:15:51 -0400 Date: Mon, 23 Apr 2018 09:15:45 -0600 From: Michal Hocko To: Mikulas Patocka Cc: Matthew Wilcox , David Miller , Andrew Morton , linux-mm@kvack.org, eric.dumazet@gmail.com, edumazet@google.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: <20180423151545.GU17484@dhcp22.suse.cz> References: <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: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > On Sat, 21 Apr 2018, 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. > > > > > 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). > > He said the same thing a year ago. And there was small progress. 6 out of > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > infiniband and 1 in btrfs. (the whole discussion is here > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) Well this is not that easy. It requires a cooperation from maintainers. I can only do as much. I've posted patches in the past and actively bringing up this topic at LSFMM last two years... > He refuses 15-line patch to fix GFP_NOIO bug because he believes that in 4 > years, the kernel will be refactored and GFP_NOIO will be eliminated. Why > does he have veto over this part of the code? I'd much rather argue with > people who have constructive comments about fixing bugs than with him. I didn't NACK the patch AFAIR. I've said it is not a good idea longterm. I would be much more willing to change my mind if you would back your patch by a real bug report. Hacks are acceptable when we have a real issue in hands. But if we want to fix potential issue then better make it properly. [...] > I sent the CONFIG_DEBUG_SG patch before (I wonder why he didn't repond to > it). I'll send a third version of the patch that actually randomly chooses > between kmalloc and vmalloc, because some abuses can only be detected with > kmalloc and we should test both. > > For bisecting, it is better to always fallback to vmalloc, but for general > testing, it is better to test both branches. Agreed! -- Michal Hocko SUSE Labs