From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757893AbcHCPe1 (ORCPT ); Wed, 3 Aug 2016 11:34:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46962 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753185AbcHCPeY (ORCPT ); Wed, 3 Aug 2016 11:34:24 -0400 Date: Wed, 3 Aug 2016 11:24:09 -0400 From: Rafael Aquini To: Andrew Morton Cc: Kyle Walker , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Geliang Tang , Vlastimil Babka , Roman Gushchin , "Kirill A. Shutemov" , Linus Torvalds Subject: Re: [PATCH] mm: Move readahead limit outside of readahead, and advisory syscalls Message-ID: <20160803152409.GB8962@t510> References: <1469457565-22693-1-git-send-email-kwalker@redhat.com> <20160725134732.b21912c54ef1ffe820ccdbca@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160725134732.b21912c54ef1ffe820ccdbca@linux-foundation.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 03 Aug 2016 15:24:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 25, 2016 at 01:47:32PM -0700, Andrew Morton wrote: > On Mon, 25 Jul 2016 10:39:25 -0400 Kyle Walker wrote: > > > Java workloads using the MappedByteBuffer library result in the fadvise() > > and madvise() syscalls being used extensively. Following recent readahead > > limiting alterations, such as 600e19af ("mm: use only per-device readahead > > limit") and 6d2be915 ("mm/readahead.c: fix readahead failure for > > memoryless NUMA nodes and limit readahead pages"), application performance > > suffers in instances where small readahead is configured. > > Can this suffering be quantified please? > > > By moving this limit outside of the syscall codepaths, the syscalls are > > able to advise an inordinately large amount of readahead when desired. > > With a cap being imposed based on the half of NR_INACTIVE_FILE and > > NR_FREE_PAGES. In essence, allowing performance tuning efforts to define a > > small readahead limit, but then benefiting from large sequential readahead > > values selectively. > > > > ... > > > > --- a/mm/readahead.c > > +++ b/mm/readahead.c > > @@ -211,7 +211,9 @@ int force_page_cache_readahead(struct address_space *mapping, struct file *filp, > > if (unlikely(!mapping->a_ops->readpage && !mapping->a_ops->readpages)) > > return -EINVAL; > > > > - nr_to_read = min(nr_to_read, inode_to_bdi(mapping->host)->ra_pages); > > + nr_to_read = min(nr_to_read, (global_page_state(NR_INACTIVE_FILE) + > > + (global_page_state(NR_FREE_PAGES)) / 2)); > > + > > while (nr_to_read) { > > int err; > > > > @@ -484,6 +486,7 @@ void page_cache_sync_readahead(struct address_space *mapping, > > > > /* be dumb */ > > if (filp && (filp->f_mode & FMODE_RANDOM)) { > > + req_size = min(req_size, inode_to_bdi(mapping->host)->ra_pages); > > force_page_cache_readahead(mapping, filp, offset, req_size); > > return; > > } > > Linus probably has opinions ;) > IIRC one of the issues Linus had with previous attempts was because they were utilizing/bringing back a node-memory state based heuristic. Since Kyle patch is using a global state counter for that matter, I think that issue condition might now be sorted out. -- Rafael