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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 37EEBC432C3 for ; Thu, 28 Nov 2019 13:56:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB7562084D for ; Thu, 28 Nov 2019 13:56:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="bQeVibLN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB7562084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 907806B0531; Thu, 28 Nov 2019 08:56:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DF136B0532; Thu, 28 Nov 2019 08:56:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F4F26B0533; Thu, 28 Nov 2019 08:56:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 6C03B6B0531 for ; Thu, 28 Nov 2019 08:56:20 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 342556115 for ; Thu, 28 Nov 2019 13:56:20 +0000 (UTC) X-FDA: 76205835720.28.glass54_37468fefabe3b X-HE-Tag: glass54_37468fefabe3b X-Filterd-Recvd-Size: 5840 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Nov 2019 13:56:19 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id f5so4422075qkm.13 for ; Thu, 28 Nov 2019 05:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=GPF1IwzBdQ5yidrnlKXQMZUft0/1YjCBcLLbgUMkwSA=; b=bQeVibLNv0W4Ge31ScS1b7LxH775Dv26sXTe3gm5YcEVqKour6+GxwH+VaEtW0AlSQ JlXrLLr6h2l8wIZJKhCuN80AcLS6nbmNTUhVyXi7bUAAXGgenJtESggHdX1NmWCfMVUa Qex01RzxAowI7SzDsRKZpVEL/LcMsaf+g4hSdIlHAU7VHwKJRuQj1RUsjNd2JhjXslls x71FVamwhCwffjJBOcSfpv9oMSLMYek9WyoErTtgjjDjPzCWRBYd+UK9NwH/PfARd7Nv 7jkOg8yXE9Km5UII4P/RzC9zdJi8dWkEG29I8NRct028QPKIeukjcwIaLiaOCbHPIB5Z 2AWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=GPF1IwzBdQ5yidrnlKXQMZUft0/1YjCBcLLbgUMkwSA=; b=c83etkWrLZlDcLi9tD/oRYvGzMr0Agaa4xx3w3WOv1Bwv765FU6q1TSkeT4ZBZGPoe qeP/kjp/Wj22B3+Flo60PA16WhI1M2wI75tpB7tZ8ZQryVeqHQfVg1vbZOelGHbdrg9p kMK+FE7wb81dR7XVI0bPMwDuTCJ8ugpOZJ6wo2XCYQgPlOKp9oT1lHrqgKP1tiwPo45+ 4H5ytbsCOXEKHd7NPuENFg7LFIqWRf+yBZluzWM0KvsecEF+6/LMlfvQQ08v0fapDiUU yzX2OXPiZnHZzNYZfEcjK5MbYgJvgvh/Z4g5Wj4G3o4jBpCRjJ0pmg5Pp35P3mx7lhmF 466w== X-Gm-Message-State: APjAAAVW+mvZ650CvcHfzIPiWkmLyp/QWzcjy3fjD9805EbIS98ENcnY whqeddUfzhCozd5Y4TYmezjn4MbqwTxByQ== X-Google-Smtp-Source: APXvYqwvpwZ1lBshgaHtwnnPvGdUJcF04QWGaWBn5/C3LdQ96sZe3+t4RvAbJfA5kkwn9wAUwIal0w== X-Received: by 2002:a05:620a:1663:: with SMTP id d3mr10482225qko.204.1574949378602; Thu, 28 Nov 2019 05:56:18 -0800 (PST) Received: from [192.168.1.183] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id v143sm8609685qka.3.2019.11.28.05.56.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Nov 2019 05:56:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Qian Cai Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v1] mm/memory_hotplug: don't check the nid in find_(smallest|biggest)_section_pfn Date: Thu, 28 Nov 2019 08:56:17 -0500 Message-Id: References: <4cfadccf-d77e-0cff-f870-0ff069d41271@redhat.com> Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Michal Hocko , Oscar Salvador In-Reply-To: <4cfadccf-d77e-0cff-f870-0ff069d41271@redhat.com> To: David Hildenbrand X-Mailer: iPhone Mail (17A878) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000219, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Nov 28, 2019, at 3:46 AM, David Hildenbrand wrote: >=20 > I'm sorry to say but one of the main reasons we have linux-next for is > to find BUGs early, before they go upstream. It is a way of giving > patches *more* testing. Yes, you are doing to dirty work (which is > highly appreciated btw) by debugging all that crap, and I can understand > how that can be frustrating. It is already an expensive development practice if developers need to rely o= n someone else to figure out their own bugs in linux-next. linux-next is for= integration testing, but majority of those regressions I had to deal with n= owadays have nothing to do with integration, i.e., interaction with other su= bsystems. >=20 > But believe me, the world won't end if your on vacation for a couple of > weeks, even though some BUGs could sneak in ... e.g., lately I try to > review as much as I can on the MM list (and Michal is steadily watching > out as well). Sure, the world will still be running, but good luck on solely rely on revie= wing with bare eyes before merging. >=20 > The solution to your problem is more review and testing, really. E.g., > I'd be very happy if other developers would test their patches more > thoroughly and if there would be more review activity on the MM list in > general (my patches barely get any review ... and I sent a lot of fixes > lately). Of course, that helps but it is a culture that very difficult to change now.= How many times I saw even high-profile developers proudly sent out patches l= abeled =E2=80=9Cno testing=E2=80=9D explicitly and implicitly ? >=20 > As soon as we stop touching our code because we are afraid of BUGs, we > lost the battle against an unmaintainable code base. Your generalizations of things make me sorrow. >=20 > BTW: [1] mentions "unbalanced software development culture with regard > to quality vs quantity that supplies an endless stream of bugs". I don't > agree to this statement. There will *always* be an endless stream of > BUGs - and most of them come from new features and performance > improvements IMHO. To me, cleanups and refactorings are important tools > to improve the software quality (and reduce the code size). All we can > do is try to minimize the number of BUGs - e.g., via more code review, > manual testing, automatic testing, and by actually understanding the > code. Cleanups/refactorings can even fix undiscovered BUGs (e.g., latest > example is [2]) Surely, most of people probably don=E2=80=99t care about those endless bugs b= ecause Linux is a monopoly in data center and open source and it is always l= ike this since Linux was born as a hobby project.=