Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 26 Sep 2002 18:04:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 26 Sep 2002 18:04:04 -0400 Received: from packet.digeo.com ([12.110.80.53]:36334 "EHLO packet.digeo.com") by vger.kernel.org with ESMTP id ; Thu, 26 Sep 2002 18:04:03 -0400 Message-ID: <3D938588.4508FDF@digeo.com> Date: Thu, 26 Sep 2002 15:09:12 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ingo Molnar CC: Linus Torvalds , Rusty Russell , linux-kernel@vger.kernel.org Subject: Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2002 22:09:09.0042 (UTC) FILETIME=[563B9920:01C265A9] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1459 Lines: 32 Ingo Molnar wrote: > > ... > another implementation would be an idea from Linus: the page's lru list > pointer can in theory be used for pinned pages (pinned pages do not have > much LRU meaning anyway), and this pointer could specify the 'owner' MM of > the physical page. The COW fault handler then checks the sticky page: Overloading page->lru in this way is tricky. If we can guarantee that the page is anonymous (anonymise it if it's file-backed, pull it out of swapcache) then fine, ->mapping, ->list.next, ->list.prev, ->index and ->private are available. Can we do that? > - if the faulting context is a non-owner (ie. the fork()-ed child), then > the normal COW path is taken - new page allocated and installed. > > - if the faulting context is the owner, then the pte chain is walked, and > the new page is installed into every 'other' pte. This needs a > cross-CPU single-page TLB flush though. The TLB flush could be > optimized if we had a way to get to the mapping MM's of the individual > pte chain entries - is this possible? Going from a pte back up to the owning MM is possible, yes. See mm/rmap.c:try_to_unmap_one(). The caller would have to hold the page's rmap_lock. - 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/