From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbcIIQTO (ORCPT ); Fri, 9 Sep 2016 12:19:14 -0400 Received: from outbound-smtp04.blacknight.com ([81.17.249.35]:49725 "EHLO outbound-smtp04.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751008AbcIIQTN (ORCPT ); Fri, 9 Sep 2016 12:19:13 -0400 Date: Fri, 9 Sep 2016 17:19:08 +0100 From: Mel Gorman To: Linus Torvalds Cc: LKML , Linux-MM , Dave Chinner , Ying Huang , Michal Hocko Subject: Re: [RFC PATCH 0/4] Reduce tree_lock contention during swap and reclaim of a single file v1 Message-ID: <20160909161908.GG8119@techsingularity.net> References: <1473415175-20807-1-git-send-email-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 09, 2016 at 08:31:27AM -0700, Linus Torvalds wrote: > On Fri, Sep 9, 2016 at 2:59 AM, Mel Gorman wrote: > > > > The progression of this series has been unsatisfactory. > > Yeah, I have to say that I particularly don't like patch #1. There isn't many ways to make it prettier. Making it nicer is partially hindered by the fact that tree_lock is IRQ-safe for IO completions but even if that was addressed there might be lock ordering issues. > It's some > rather nasty complexity for dubious gains, and holding the lock for > longer times might have downsides. > Kswapd reclaim would delay a parallel truncation for example. Doubtful it matters but the possibility is there. The gain in swapping is nice but ramdisk is excessively artifical. It might matter if someone reported it made a big difference swapping to faster storage like SSD or NVMe although the cases where fast swap is important are few -- overcommitted host with multiple idle VMs with a new active VM starting is the only one that springs to mind. > So I think this series is one of those "we need to find that it makes > a big positive impact" to make sense. > Agreed. I don't mind leaving it on the back burner unless Dave reports it really helps or a new bug report about realistic tree_lock contention shows up. -- Mel Gorman SUSE Labs