From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 968C0C388F9 for ; Sun, 8 Nov 2020 03:22:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03D4A207C3 for ; Sun, 8 Nov 2020 03:22:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="jZWJehsi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03D4A207C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 614476B0068; Sat, 7 Nov 2020 22:22:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C5546B006C; Sat, 7 Nov 2020 22:22:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48DAF6B006E; Sat, 7 Nov 2020 22:22:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 134E66B0068 for ; Sat, 7 Nov 2020 22:22:15 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9DCD6180AD802 for ; Sun, 8 Nov 2020 03:22:14 +0000 (UTC) X-FDA: 77459802588.10.wave04_360ca3a272e0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 789D716A07F for ; Sun, 8 Nov 2020 03:22:14 +0000 (UTC) X-HE-Tag: wave04_360ca3a272e0 X-Filterd-Recvd-Size: 4886 Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Sun, 8 Nov 2020 03:22:13 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Sat, 07 Nov 2020 19:22:16 -0800 Received: from [10.2.62.222] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Nov 2020 03:22:11 +0000 Subject: Re: [PATCH] mm/gup_benchmark: GUP_BENCHMARK depends on DEBUG_FS From: John Hubbard To: "Song Bao Hua (Barry Song)" , Randy Dunlap , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" CC: Linuxarm , Ralph Campbell , John Garry References: <20201104100552.20156-1-song.bao.hua@hisilicon.com> <9286e2d0e17a47a1874dc4a96d83a38f@hisilicon.com>

<2c968615-587c-b978-7961-8391c70382b2@nvidia.com> <869059977c224a3aa31bfb42a4a8148d@hisilicon.com> Message-ID: <8eaa47c0-a62d-46da-4fd6-93f2b5b2910d@nvidia.com> Date: Sat, 7 Nov 2020 19:22:11 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1604805736; bh=YGcLdm9d0VYDsmVEG1tRIXb/IlxQJmH1cfsqcVcm74k=; h=Subject:From:To:CC:References:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=jZWJehsiSxpYO1odWNB3iw+cEQa263UyQEp0cqUU9L5fu2Y01DuU2D8qmU2Ebz2Tv 76YGhMH3HHTxZekz4NH4eSGmlihCyK21ybBYZiWfCcnpqiTzD9NawHwBAkqtvE2HQu psnOU3baQC7galC+jLEHsQxvQTPZurRDrw6qX3+I5q2+GU/a9GFCKHUsSiQqF585Lp rCeLRptsUtcABsionZbdwdCWtp+qLPPmpF0Uj4Hqzu5jrDANyQ+8zalbCyiUeOqVZS bYz5lyPiFFzyBd2fiBHid6G4fgiR+dQAhO1bcH8kCutKeolFLivRM9Z/k8jkyF33pu LJ+6R4DY5jl7g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/7/20 7:14 PM, John Hubbard wrote: > On 11/7/20 6:58 PM, Song Bao Hua (Barry Song) wrote: >>> On 11/7/20 2:20 PM, Randy Dunlap wrote: >>>> On 11/7/20 11:16 AM, John Hubbard wrote: >>>>> On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote: >>>>>>> From: John Hubbard [mailto:jhubbard@nvidia.com] >>>>> ... >>> But if you really disagree, then I'd go with, just drop the patch entirely, because >>> it doesn't really make things better as written...IMHO anyway. :) >> >> Just imagine a case, we don't enable DEBUG_FS but we enable GUP_TEST, we will >> get an image with totally useless code section since GUP_TEST depends on debugfs >> entry to perform any useful functionality. >> > > Looking at the choices, from the user's (usually kernel developer's) experience: > > a) The user enables GUP_TEST, then boots up, runs, and is briefly surprised by a > runtime failure. But it's a very quick diagnosis: "open: No such file or directory", > when trying to make that ioctl call. The path indicates that it's a debug fs path, > so the solution is pretty clear, at least for the main audience. > > b) The other choice: the user *never even sees* GUP_TEST as a choice. This especially > bothers me because sometimes you find things by poking around in the menu, although > of course "you should already know about it"...but there's a lot to "already know" > in a large kernel. > > From a user experience, it's way better to simply see what you want, and select it > in the menu. Or, at least get some prompt that you need to pre-select something else. > ...and again, this is all fallout from Kconfig. I might be missing some advanced feature, because it seems surprising to only be allowed to choose between missing dependencies (which this patch would correct), or a poorer user experience (which I argue that this patch would also provide). Ideally, we'd just set up the dependencies, and then have some options for visibility, but I'm not aware of any way to do that...and after a quick peek at Documentation/kbuild/kconfig-macro-language.rst it looks pretty bare bones. thanks, -- John Hubbard NVIDIA