From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by kanga.kvack.org (Postfix) with ESMTP id 286056B0035 for ; Thu, 23 Jan 2014 00:06:35 -0500 (EST) Received: by mail-pb0-f51.google.com with SMTP id un15so1365660pbc.38 for ; Wed, 22 Jan 2014 21:06:34 -0800 (PST) Received: from LGEAMRELO01.lge.com (lgeamrelo01.lge.com. [156.147.1.125]) by mx.google.com with ESMTP id mj6si12485966pab.159.2014.01.22.21.06.12 for ; Wed, 22 Jan 2014 21:06:33 -0800 (PST) Date: Thu, 23 Jan 2014 14:07:28 +0900 From: Minchan Kim Subject: Re: [patch 5/9] mm + fs: prepare for non-page entries in page cache radix trees Message-ID: <20140123050728.GB28732@bbox> References: <1389377443-11755-1-git-send-email-hannes@cmpxchg.org> <1389377443-11755-6-git-send-email-hannes@cmpxchg.org> <20140113020132.GO1992@bbox> <20140122174744.GC4407@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140122174744.GC4407@cmpxchg.org> Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Andrew Morton , Andi Kleen , Andrea Arcangeli , Bob Liu , Christoph Hellwig , Dave Chinner , Greg Thelen , Hugh Dickins , Jan Kara , KOSAKI Motohiro , Luigi Semenzato , Mel Gorman , Metin Doslu , Michel Lespinasse , Ozgun Erdogan , Peter Zijlstra , Rik van Riel , Roman Gushchin , Ryan Mallon , Tejun Heo , Vlastimil Babka , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Hi Hannes, On Wed, Jan 22, 2014 at 12:47:44PM -0500, Johannes Weiner wrote: > On Mon, Jan 13, 2014 at 11:01:32AM +0900, Minchan Kim wrote: > > On Fri, Jan 10, 2014 at 01:10:39PM -0500, Johannes Weiner wrote: > > > shmem mappings already contain exceptional entries where swap slot > > > information is remembered. > > > > > > To be able to store eviction information for regular page cache, > > > prepare every site dealing with the radix trees directly to handle > > > entries other than pages. > > > > > > The common lookup functions will filter out non-page entries and > > > return NULL for page cache holes, just as before. But provide a raw > > > version of the API which returns non-page entries as well, and switch > > > shmem over to use it. > > > > > > Signed-off-by: Johannes Weiner > > Reviewed-by: Minchan Kim > > Thanks, Minchan! > > > > @@ -890,6 +973,73 @@ repeat: > > > EXPORT_SYMBOL(find_or_create_page); > > > > > > /** > > > + * __find_get_pages - gang pagecache lookup > > > + * @mapping: The address_space to search > > > + * @start: The starting page index > > > + * @nr_pages: The maximum number of pages > > > + * @pages: Where the resulting pages are placed > > > > where is @indices? > > Fixed :) > > > > @@ -894,6 +894,53 @@ EXPORT_SYMBOL(__pagevec_lru_add); > > > > > > /** > > > * pagevec_lookup - gang pagecache lookup > > > > __pagevec_lookup? > > > > > + * @pvec: Where the resulting entries are placed > > > + * @mapping: The address_space to search > > > + * @start: The starting entry index > > > + * @nr_pages: The maximum number of entries > > > > missing @indices? > > > > > + * > > > + * pagevec_lookup() will search for and return a group of up to > > > + * @nr_pages pages and shadow entries in the mapping. All entries are > > > + * placed in @pvec. pagevec_lookup() takes a reference against actual > > > + * pages in @pvec. > > > + * > > > + * The search returns a group of mapping-contiguous entries with > > > + * ascending indexes. There may be holes in the indices due to > > > + * not-present entries. > > > + * > > > + * pagevec_lookup() returns the number of entries which were found. > > > > __pagevec_lookup > > Yikes, all three fixed. > > > > @@ -22,6 +22,22 @@ > > > #include > > > #include "internal.h" > > > > > > +static void clear_exceptional_entry(struct address_space *mapping, > > > + pgoff_t index, void *entry) > > > +{ > > > + /* Handled by shmem itself */ > > > + if (shmem_mapping(mapping)) > > > + return; > > > + > > > + spin_lock_irq(&mapping->tree_lock); > > > + /* > > > + * Regular page slots are stabilized by the page lock even > > > + * without the tree itself locked. These unlocked entries > > > + * need verification under the tree lock. > > > + */ > > > > Could you explain why repeated spin_lock with irq disabled isn't problem > > in truncation path? > > To modify the cache tree, we have to take the IRQ-safe tree_lock, this > is no different than removing a page (see truncate_complete_page). I meant we can do batch irq_[lock|unlock] part with periodic irq release because clear_exceptional_entry is always called with gang pagecache lookup. Just a comment about optimiztation so it shouldn't be critical for merging and we could do in future if it's really problem for scalability. -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org