Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 27 Sep 2002 12:58:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 27 Sep 2002 12:58:37 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:9229 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 27 Sep 2002 12:58:36 -0400 Date: Fri, 27 Sep 2002 10:05:17 -0700 (PDT) From: Linus Torvalds To: Ingo Molnar cc: Andrew Morton , Rusty Russell , Subject: Re: [patch] 'virtual => physical page mapping cache', vcache-2.5.38-B8 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1281 Lines: 27 On Fri, 27 Sep 2002, Ingo Molnar wrote: > > i agree, first hashing the vcache should work. There are some details: > if we first hash the vcache then we have to set up the queue in a way for > the callback function to notice that this queue is not futex-hashed (ie. > not live) yet. Otherwise the callback function might attempt to rehash it. > This means one more branch in the callback function, not a problem. Not necessarily. You can solve _this_ problem by just holding the futex lock over the whole operation. If the COW happens "early" on another CPU, it will then be serialized by the futex lock in the callback function. The futex lock itself is hopefully not going to be contended very much, making the "get it early" approach acceptable. Although if it later _does_ get contended, we'll need to split it up some way: it cannot be hashed sanely with the above approach, since there are no unique sub-indexes to hash off as the physical page and offset have zero correlation with the VM / virtual address. Linus - 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/