From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 3 Mar 2003 11:46:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 3 Mar 2003 11:46:57 -0500 Received: from mx1.elte.hu ([157.181.1.137]:4009 "HELO mx1.elte.hu") by vger.kernel.org with SMTP id ; Mon, 3 Mar 2003 11:46:55 -0500 Date: Mon, 3 Mar 2003 17:56:57 +0100 (CET) From: Ingo Molnar Reply-To: Ingo Molnar To: Linus Torvalds Cc: Andrew Morton , , Subject: Re: [patch] remap-file-pages-2.5.63-A0 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 On Mon, 3 Mar 2003, Linus Torvalds wrote: > > the attached patch, against BK-curr, is a preparation to make > > remap_file_pages() usable on swappable vmas as well. When 'swapping out' > > shared-named mappings the page offset is written into the pte. > > > > it takes one bit from the swap-type bits, otherwise it does not change the > > pte layout - so it should be easy to adapt any other architecture to this > > change as well. (this patch does not introduce the protection-bits-in-pte > > approach used in my previous patch.) > > One question: Why? > > What's wrong with just using the value we use now (0), and just > calculating the page from the vma/offset information? Why hide the > offset in the page tables, when there is no need for it? you mean why in the normal, linear mapping case? No reason, just for testing. At zap-time we could test whether that pte is linear or not, and only store it in the swap entry as a file-pte if it's nonlinear. for swappable sys_file_remap_pages() support it's necessary though, as they break up the linear mapping without splitting up the vma into zillions of pieces. Ingo