Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 26 Sep 2002 18:48:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 26 Sep 2002 18:48:59 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:12298 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Thu, 26 Sep 2002 18:48:22 -0400 Date: Thu, 26 Sep 2002 15:56:29 -0700 (PDT) From: Linus Torvalds To: Andrew Morton cc: Ingo Molnar , Rusty Russell , Subject: Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 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: 1467 Lines: 35 On Thu, 26 Sep 2002, Linus Torvalds wrote: > > and then when we pin a page, we do > > /* This is part of the > struct page_change_struct pinned_data; That "This is part of the " comment should continue with "struct futex_q", but I went off and was supposed to check what the futex data structure was called, and forgot about updating it. Anyway, the point being that this needs no new allocations in _any_ path, and only extends a structure that we already need for the slow case for futexes. It does imply a new lock, though, and the COW path would have to check that hash (which should scale pretty well, since we only have entries here when somebody is blocked on a futex). Oh, and we need a new hash table, since the native futex hash can't just be re-used due to different indexing - the futex hash is based on physical page and offset, while the page_change_struct hash is based on virtual address and the mm. (I initially thought we could make the page_change_struct hash be based on physical page, but there can be multiple instances of the same physical page being mapped into the same VM, so that wouldn't be a good thing - we'd get callbacks for the wrong virtual address being COW'ed). 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/