Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753498AbaBYTaG (ORCPT ); Tue, 25 Feb 2014 14:30:06 -0500 Received: from g2t2353.austin.hp.com ([15.217.128.52]:55066 "EHLO g2t2353.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009AbaBYTaE (ORCPT ); Tue, 25 Feb 2014 14:30:04 -0500 Message-ID: <1393356602.2577.54.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v2] 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: Tue, 25 Feb 2014 11:30:02 -0800 In-Reply-To: <1393355040.2577.52.camel@buesod1.americas.hpqcorp.net> References: <1393352206.2577.36.camel@buesod1.americas.hpqcorp.net> <1393355040.2577.52.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 Tue, 2014-02-25 at 11:04 -0800, Davidlohr Bueso wrote: > On Tue, 2014-02-25 at 10:37 -0800, Linus Torvalds wrote: > > On Tue, Feb 25, 2014 at 10:16 AM, Davidlohr Bueso wrote: > > > index a17621c..14396bf 100644 > > > --- a/kernel/fork.c > > > +++ b/kernel/fork.c > > > @@ -363,7 +363,12 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) > > > > > > mm->locked_vm = 0; > > > mm->mmap = NULL; > > > - mm->mmap_cache = NULL; > > > + mm->vmacache_seqnum = oldmm->vmacache_seqnum + 1; > > > + > > > + /* deal with overflows */ > > > + if (unlikely(mm->vmacache_seqnum == 0)) > > > + vmacache_invalidate_all(); > > > > Correct me if I'm wrong, but this can not possibly be correct. > > > > vmacache_invalidate_all() walks over all the threads of the current > > process, but "mm" here is the mm of the *new* process that is getting > > created, and is unrelated in all ways to the threads of the old > > process. > > vmacache_invalidate_all() is actually a misleading name since we really > aren't invalidating but just clearing the cache. I'll rename it. > Anyways... > > > So it walks completely the wrong list of threads. > > But we still need to deal with the rest of the tasks in the system, so > anytime there's an overflow we need to nullify all cached vmas, not just > current's. Am I missing something special about fork? > > > In fact, the sequence number of the old vm and the sequence number of > > the new vm cannot in any way be related. > > > > As far as I can tell, the only sane thing to do at fork/clone() time is to: > > > > - clear all the cache entries (of the new 'struct task_struct'! - so > > not in dup_mmap, but make sure it's zeroed when allocating!)( > > Right, but that's done upon the first lookup, when vmacache_valid() is > false. > > > - set vmcache_seqnum to 0 in dup_mmap (since any sequence number is > > fine when it got invalidated, and 0 is best for "avoid overflow"). > > Assuming your referring to curr->vmacache_seqnum (since mm's is already > set).. isn't it irrelevant since we set it anyways when the first lookup > fails? Never mind, I see your referring to the mm seqnum. Sounds like it's an interesting alternative to the CONFIG_MMU workaround. I will look into it. Thanks, Davidlohr -- 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/