From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753564AbeDZTOS convert rfc822-to-8bit (ORCPT ); Thu, 26 Apr 2018 15:14:18 -0400 Received: from mail.stoffel.org ([104.236.43.127]:58090 "EHLO mail.stoffel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128AbeDZTOR (ORCPT ); Thu, 26 Apr 2018 15:14:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: <23266.8532.619051.784274@quad.stoffel.home> Date: Thu, 26 Apr 2018 14:58:28 -0400 From: "John Stoffel" To: James Bottomley Cc: Mikulas Patocka , Michal@stoffel.org, eric.dumazet@gmail.com, mst@redhat.com, netdev@vger.kernel.org, jasowang@redhat.com, Randy Dunlap , linux-kernel@vger.kernel.org, Matthew Wilcox , Hocko , linux-mm@kvack.org, dm-devel@redhat.com, Vlastimil Babka , Andrew@stoffel.org, David Rientjes , Morton , virtualization@lists.linux-foundation.org, David Miller , edumazet@google.com Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options In-Reply-To: <1524697697.4100.23.camel@HansenPartnership.com> References: <20180421144757.GC14610@bombadil.infradead.org> <20180423151545.GU17484@dhcp22.suse.cz> <20180424125121.GA17484@dhcp22.suse.cz> <20180424162906.GM17484@dhcp22.suse.cz> <20180424170349.GQ17484@dhcp22.suse.cz> <20180424173836.GR17484@dhcp22.suse.cz> <1114eda5-9b1f-4db8-2090-556b4a37c532@infradead.org> <1524694663.4100.21.camel@HansenPartnership.com> <1524697697.4100.23.camel@HansenPartnership.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64-pc-linux-gnu) X-Clacks-Overhead: GNU Terry Pratchett Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>>> "James" == James Bottomley writes: James> On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote: >> >> On Wed, 25 Apr 2018, James Bottomley wrote: >> >> > > > Do we really need the new config option?  This could just be >> > > > manually  tunable via fault injection IIUC. >> > >  >> > > We do, because we want to enable it in RHEL and Fedora debugging >> > > kernels, so that it will be tested by the users. >> > >  >> > > The users won't use some extra magic kernel options or debugfs >> files. >> >  >> > If it can be enabled via a tunable, then the distro can turn it on >> > without the user having to do anything.  If you want to present the >> > user with a different boot option, you can (just have the tunable >> set >> > on the command line), but being tunable driven means that you don't >> > have to choose that option, you could automatically enable it under >> a >> > range of circumstances.  I think most sane distributions would want >> > that flexibility. >> >  >> > Kconfig proliferation, conversely, is a bit of a nightmare from >> both >> > the user and the tester's point of view, so we're trying to avoid >> it >> > unless absolutely necessary. >> >  >> > James >> >> BTW. even developers who compile their own kernel should have this >> enabled by a CONFIG option - because if the developer sees the option >> when browsing through menuconfig, he may enable it. If he doesn't see >> the option, he won't even know that such an option exists. James> I may be an atypical developer but I'd rather have a root canal James> than browse through menuconfig options. The way to get people James> to learn about new debugging options is to blog about it (or James> write an lwn.net article) which google will find the next time James> I ask it how I debug XXX. Google (probably as a service to James> humanity) rarely turns up Kconfig options in response to a James> query. I agree with James here. Looking at the SLAB vs SLUB Kconfig entries tells me *nothing* about why I should pick one or the other, as an example. John