From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965171AbXCGMnF (ORCPT ); Wed, 7 Mar 2007 07:43:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965193AbXCGMnE (ORCPT ); Wed, 7 Mar 2007 07:43:04 -0500 Received: from amsfep20-int.chello.nl ([62.179.120.15]:35029 "EHLO amsfep20-int.chello.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965171AbXCGMnC (ORCPT ); Wed, 7 Mar 2007 07:43:02 -0500 Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) From: Peter Zijlstra To: Nick Piggin Cc: Miklos Szeredi , akpm@linux-foundation.org, mingo@elte.hu, linux-mm@kvack.org, linux-kernel@vger.kernel.org, benh@kernel.crashing.org, Jeff Dike In-Reply-To: <20070307121730.GC18704@wotan.suse.de> References: <20070307094503.GD8609@wotan.suse.de> <20070307100430.GA5080@wotan.suse.de> <1173262002.6374.128.camel@twins> <20070307102106.GB5555@wotan.suse.de> <1173263085.6374.132.camel@twins> <20070307103842.GD5555@wotan.suse.de> <1173264462.6374.140.camel@twins> <20070307110035.GE5555@wotan.suse.de> <1173268086.6374.157.camel@twins> <20070307121730.GC18704@wotan.suse.de> Content-Type: text/plain Date: Wed, 07 Mar 2007 13:41:26 +0100 Message-Id: <1173271286.6374.166.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2007-03-07 at 13:17 +0100, Nick Piggin wrote: > > Tracking these ranges on a per-vma basis would avoid taking the mm wide > > mmap_sem and so would be cheaper than regular vmas. > > > > Would that still be too expensive? > > Well you can today remap N pages in a file, arbitrarily for > sizeof(pte_t)*tiny bit for the upper page tables + small constant > for the vma. > > At best, you need an extra pointer to pte / vaddr, so you'd basically > double memory overhead. I was hoping some form of range compression would gain something, but if its a fully random mapping, then yes a shadow page table would be needed (still looking into what a pte_chain is) > > > > Well, now they don't, but it could be done or even exploited as a DoS. > > > > > > But so could nonlinear page reclaim. I think we need to restrict nonlinear > > > mappings to root if we're worried about that. > > > > Can't we just 'fix' it? > > The thing is, I don't think anybody who uses these things cares > about any of the 'problems' you want to fix, do they? We are > interested in dirty pages only for the correctness issue, rather > than performance. Same as reclaim. If so, we can just stick to the dead slow but correct 'scan the full vma' page_mkclean() and nobody would ever trigger it. What is the DoS scenario wrt reclaim? We really ought to fix that if real, those UML farms run on nothing but nonlinear reclaim I'd think.