Re: [patch 4/6] mm: merge populate and nopage into fault (fixesnonlinear)

[Peter Zijlstra]

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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/