Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1377621imd; Thu, 1 Nov 2018 14:46:35 -0700 (PDT) X-Google-Smtp-Source: AJdET5eDitarEVFnwUj+9rhKjtgi9YjMAdOD5tEJp1Vojid65t5K7EPEbCesELb6KsIPgRLqHIsU X-Received: by 2002:a63:413:: with SMTP id 19mr8597263pge.7.1541108795675; Thu, 01 Nov 2018 14:46:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541108795; cv=none; d=google.com; s=arc-20160816; b=seb5OCr0/FLQmyzpr1INtZQTCjzPqfLEMJo4o83QNXkxA5Cn+nZWwqKMCxg9R3n6gT 8AUyYP5YqSlHCHWE7DCTahlS9AtfwOMcAoKDaKGqEk4pyRIm7lRFMdHH9okE+8j15009 R/WG1vkFq8mzwrlMUnOe1xgi8XoF+cMGMzZZSV0rj/v1XoIZ0qc8jQPX7zcNxRxUASsb RMFLPRpGKkiRw9VPjOwy/cwhhihrXHNnuPI1TTRNKGtslPYKdDDGQSmqkRhveCj9FK+u za7rzbA79VCmbBFe9KQEpbrofA4C/KsljGmsARUPd0CjK6vjXj8s8/1uMgTuOVQPM51G v9Fg== 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; bh=dZZ9zU+e1zCkzknLvOoamfHiSza5MExwIywV4kcgkXI=; b=NXTIRhcGbD5Qi94PhcCyBFeRd11mPDrx6l5ZcL+/kqJMwK905SD/5mlsKVPN9sJHph VA2TC0M9it7pHqlpbfXQnX6WUDUvACxhStc+QLUdEpHBmwNB2WMOuY5crQPmcA3W+v47 1Xe8Wxemv1IACAtV5xzYnMT5uk6mb1FDv+T2TWSAv4FB4kaVU2klAsy8NaXRSBxyLkPM gR/aJlfE2IN3G0g26VoNZfpHt1jPpNhqvQvUnPaFpVJpIUmp2p5+eOLVmoYXep3yGouZ Jb1xs8auYnK/1Rw6PNd+3uZyEWQv1bkFIN1ZWjWYU3biLzVNVLxArgunZh8ykU/8BNKu LGNw== 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 s17-v6si30930698pge.209.2018.11.01.14.46.21; Thu, 01 Nov 2018 14:46:35 -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 S1727715AbeKBGuR (ORCPT + 99 others); Fri, 2 Nov 2018 02:50:17 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:54767 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727151AbeKBGuR (ORCPT ); Fri, 2 Nov 2018 02:50:17 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 3C3CC807F4; Thu, 1 Nov 2018 22:45:27 +0100 (CET) Date: Thu, 1 Nov 2018 22:45:28 +0100 From: Pavel Machek To: Greg KH Cc: Hugh Dickins , Jan Kara , linux-kernel , stable , Mel Gorman , Andrew Morton , Linus Torvalds , Mel Gorman Subject: Re: [PATCH 4.4 50/92] mm: filemap: avoid unnecessary calls to lock_page when waiting for IO to complete during a read Message-ID: <20181101214528.GA1552@xo-6d-61-c0.localdomain> References: <20180524093159.286472249@linuxfoundation.org> <20180524093204.290399449@linuxfoundation.org> <20180524105011.jkmjrmoyqtogtgnn@quack2.suse.cz> <20180524110546.GA16171@kroah.com> <20180524112841.GA17626@kroah.com> <20180524190611.GD31019@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180524190611.GD31019@kroah.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > > > I've no wish to be disputatious, but it does seem that the definition of > > > > "stable" has changed, and not necessarily for the better, if it's now a > > > > home for small gains: I thought we left those to upstream. > > > > > This is in the SLES kernel for a reason, and again, it's in the section > > > that says "this should be pushed to stable". So if it's good enough for > > > the SLES kernel, why isn't it good enough for all users of this kernel > > > tree? > > > > > If you all think it should be dropped in both places, that's fine with > > > me :) > > > > I think they are perfectly fine in SLES: folding in good work is a part of > > what distros are about. > > And it's also what stable is for. We have had backports of performance > improvements in the past, along with lots of other things over the > years. This is a performance improvement. A tiny one, yes, but getting > rid of a lock is a good thing, and I picked it up as part of my review > of what a distro decided was worth adding for their users, as that's a > huge signal that might be of value to others. > > > But I cannot find anything in stable-kernel-rules.rst that would admit them > > - perhaps that's just out of date? > > Nope, that's the list I use to say "no" to. You can't describe > everything in that file, it's a judgement call. Well, it would be good if the documentation matched reality, because other people use the documentation to decide, too. For example, documentation says bug has to be fixed in mainline, but in actual practice you try to have exactly the same patch. Pavel