Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753787AbaBVEz7 (ORCPT ); Fri, 21 Feb 2014 23:55:59 -0500 Received: from g2t2352.austin.hp.com ([15.217.128.51]:27034 "EHLO g2t2352.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752775AbaBVEz5 (ORCPT ); Fri, 21 Feb 2014 23:55:57 -0500 X-Greylist: delayed 1479 seconds by postgrey-1.27 at vger.kernel.org; Fri, 21 Feb 2014 23:55:57 EST Message-ID: <1393044955.2473.5.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH] mm: per-thread vma caching From: Davidlohr Bueso To: Linus Torvalds Cc: Andrew Morton , Ingo Molnar , Peter Zijlstra , Michel Lespinasse , Mel Gorman , Rik van Riel , KOSAKI Motohiro , "Chandramouleeswaran, Aswin" , "Norton, Scott J" , linux-mm , Linux Kernel Mailing List Date: Fri, 21 Feb 2014 20:55:55 -0800 In-Reply-To: References: <1392960523.3039.16.camel@buesod1.americas.hpqcorp.net> <1393016226.3039.44.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-02-21 at 13:24 -0800, Linus Torvalds wrote: > On Fri, Feb 21, 2014 at 12:57 PM, Davidlohr Bueso wrote: > > > > Btw, one concern I had is regarding seqnum overflows... if such > > scenarios should happen we'd end up potentially returning bogus vmas and > > getting bus errors and other sorts of issues. So we'd have to flush the > > caches, but, do we care? I guess on 32bit systems it could be a bit more > > possible to trigger given enough forking. > > I guess we should do something like > > if (unlikely(!++seqnum)) > flush_vma_cache() > > just to not have to worry about it. > > And we can either use a "#ifndef CONFIG_64BIT" to disable it for the > 64-bit case (because no, we really don't need to worry about overflow > in 64 bits ;), or just decide that a 32-bit sequence number actually > packs better in the structures, and make it be an "u32" even on 64-bit > architectures? > > It looks like a 32-bit sequence number might pack nicely next to the > > unsigned brk_randomized:1; And probably specially so for structures like task and mm. I hadn't considered the benefits of packing vs overflowing. So we can afford flushing all tasks's vmacache every 4 billion forks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/