From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757492AbdACFn6 (ORCPT ); Tue, 3 Jan 2017 00:43:58 -0500 Received: from mga11.intel.com ([192.55.52.93]:18900 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756457AbdACFnt (ORCPT ); Tue, 3 Jan 2017 00:43:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,451,1477983600"; d="scan'208";a="918332499" From: "Huang\, Ying" To: Minchan Kim Cc: Jan Kara , Tim Chen , Andrew Morton , Ying Huang , , , , , , Hugh Dickins , Shaohua Li , Rik van Riel , Andrea Arcangeli , "Kirill A . Shutemov" , Vladimir Davydov , Johannes Weiner , Michal Hocko , Hillf Danton , "Christian Borntraeger" , Jonathan Corbet , Peter Zijlstra , Nicholas Piggin Subject: Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations References: <20161227074503.GA10616@bbox> <20170102154841.GG18058@quack2.suse.cz> <20170103043411.GA15657@bbox> Date: Tue, 03 Jan 2017 13:43:43 +0800 In-Reply-To: <20170103043411.GA15657@bbox> (Minchan Kim's message of "Tue, 3 Jan 2017 13:34:11 +0900") Message-ID: <87inpwu29c.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Minchan, Minchan Kim writes: > Hi Jan, > > On Mon, Jan 02, 2017 at 04:48:41PM +0100, Jan Kara wrote: >> Hi, >> >> On Tue 27-12-16 16:45:03, Minchan Kim wrote: >> > > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing >> > > the rate that we have to contende for the radix tree. >> > >> > To me, it's rather hacky. I think it might be common problem for page cache >> > so can we think another generalized way like range_lock? Ccing Jan. >> >> I agree on the hackyness of the patch and that page cache would suffer with >> the same contention (although the files are usually smaller than swap so it >> would not be that visible I guess). But I don't see how range lock would >> help here - we need to serialize modifications of the tree structure itself >> and that is difficult to achieve with the range lock. So what you would >> need is either a different data structure for tracking swap cache entries >> or a finer grained locking of the radix tree. > > Thanks for the comment, Jan. > > I think there are more general options. One is to shrink batching pages like > Mel and Tim had approached. > > https://patchwork.kernel.org/patch/9008421/ > https://patchwork.kernel.org/patch/9322793/ This helps to reduce the lock contention on radix tree of swap cache. But splitting swap cache has much better performance. So we switched from that solution to current solution. > Or concurrent page cache by peter. > > https://www.kernel.org/doc/ols/2007/ols2007v2-pages-311-318.pdf I think this is good, it helps swap and file cache. But I don't know whether other people want to go this way and how much effort will be needed. In contrast, splitting swap cache is quite simple, for implementation and review. And the effect is good. Best Regards, Huang, Ying > Ccing Nick who might have an interest on lockless page cache. > > Thanks.