From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753715AbaBYTrJ (ORCPT ); Tue, 25 Feb 2014 14:47:09 -0500 Received: from merlin.infradead.org ([205.233.59.134]:51955 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413AbaBYTrH (ORCPT ); Tue, 25 Feb 2014 14:47:07 -0500 Date: Tue, 25 Feb 2014 20:46:49 +0100 From: Peter Zijlstra To: Davidlohr Bueso Cc: Andrew Morton , Ingo Molnar , Linus Torvalds , Michel Lespinasse , Mel Gorman , Rik van Riel , KOSAKI Motohiro , aswin@hp.com, scott.norton@hp.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: per-thread vma caching Message-ID: <20140225194649.GV6835@laptop.programming.kicks-ass.net> References: <1393352206.2577.36.camel@buesod1.americas.hpqcorp.net> <20140225183522.GU6835@laptop.programming.kicks-ass.net> <1393353454.2577.42.camel@buesod1.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393353454.2577.42.camel@buesod1.americas.hpqcorp.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 25, 2014 at 10:37:34AM -0800, Davidlohr Bueso wrote: > On Tue, 2014-02-25 at 19:35 +0100, Peter Zijlstra wrote: > > On Tue, Feb 25, 2014 at 10:16:46AM -0800, Davidlohr Bueso wrote: > > > +void vmacache_update(struct mm_struct *mm, unsigned long addr, > > > + struct vm_area_struct *newvma) > > > +{ > > > + /* > > > + * Hash based on the page number. Provides a good > > > + * hit rate for workloads with good locality and > > > + * those with random accesses as well. > > > + */ > > > + int idx = (addr >> PAGE_SHIFT) & 3; > > > > % VMACACHE_SIZE > > > > perhaps? GCC should turn that into a mask for all sensible values I > > would think. > > > > Barring that I think something like: > > > > #define VMACACHE_BITS 2 > > #define VMACACHE_SIZE (1U << VMACACHE_BITS) > > #define VMACACHE_MASK (VMACACHE_SIZE - 1) > > Hmm all that seems like an overkill. If GCC does the right thing with % VMACACHE_SIZE it gets rid of an ugly constant. But the 3 VMACACHE_* things are 'better' in that its impossible to set VMACACHE_SIZE to silly values. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by kanga.kvack.org (Postfix) with ESMTP id 2C9EE6B0092 for ; Tue, 25 Feb 2014 14:47:05 -0500 (EST) Received: by mail-ie0-f175.google.com with SMTP id at1so780527iec.6 for ; Tue, 25 Feb 2014 11:47:05 -0800 (PST) Received: from merlin.infradead.org (merlin.infradead.org. [2001:4978:20e::2]) by mx.google.com with ESMTPS id q7si40015331igh.19.2014.02.25.11.47.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2014 11:47:01 -0800 (PST) Date: Tue, 25 Feb 2014 20:46:49 +0100 From: Peter Zijlstra Subject: Re: [PATCH v2] mm: per-thread vma caching Message-ID: <20140225194649.GV6835@laptop.programming.kicks-ass.net> References: <1393352206.2577.36.camel@buesod1.americas.hpqcorp.net> <20140225183522.GU6835@laptop.programming.kicks-ass.net> <1393353454.2577.42.camel@buesod1.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393353454.2577.42.camel@buesod1.americas.hpqcorp.net> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Andrew Morton , Ingo Molnar , Linus Torvalds , Michel Lespinasse , Mel Gorman , Rik van Riel , KOSAKI Motohiro , aswin@hp.com, scott.norton@hp.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org On Tue, Feb 25, 2014 at 10:37:34AM -0800, Davidlohr Bueso wrote: > On Tue, 2014-02-25 at 19:35 +0100, Peter Zijlstra wrote: > > On Tue, Feb 25, 2014 at 10:16:46AM -0800, Davidlohr Bueso wrote: > > > +void vmacache_update(struct mm_struct *mm, unsigned long addr, > > > + struct vm_area_struct *newvma) > > > +{ > > > + /* > > > + * Hash based on the page number. Provides a good > > > + * hit rate for workloads with good locality and > > > + * those with random accesses as well. > > > + */ > > > + int idx = (addr >> PAGE_SHIFT) & 3; > > > > % VMACACHE_SIZE > > > > perhaps? GCC should turn that into a mask for all sensible values I > > would think. > > > > Barring that I think something like: > > > > #define VMACACHE_BITS 2 > > #define VMACACHE_SIZE (1U << VMACACHE_BITS) > > #define VMACACHE_MASK (VMACACHE_SIZE - 1) > > Hmm all that seems like an overkill. If GCC does the right thing with % VMACACHE_SIZE it gets rid of an ugly constant. But the 3 VMACACHE_* things are 'better' in that its impossible to set VMACACHE_SIZE to silly values. -- 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