OK, will try to reproduce that.
> - nasty, nasty problems with remap_file_pages(). I'd rather not have to
> nobble remap_file_pages() functionality for this reason.
I don't see having to predeclare the thing as non-linear as a serious
imposition .... I don't think memlocking them is necessary, AFAICS if
we have that.
> and what do we gain from it all? The small fork/exec boost isn't very
> significant. What we gain is more lowmem space on
> going-away-real-soon-now-we-sincerely-hope highmem boxes.
They're not going away soon (unfortunately) - even if Intel stopped producing
the chips today, the machines based on them are still in the marketplace for
years.
The performance improvement was about 25% of systime according to my
measurements - I don't call that insignificant.
> Ingo-rmap seems a better solution to me. It would be a fairly large change
> though - we'd have to hold the four atomic kmaps across an entire pte page
> in copy_page_range(), for example. But it will then have good locality of
> reference between adjacent pages and may well be quicker than pte_chains.
If there was an existing implementation we could actually measure, I'd
be more impressed. From what I can see currently, it'll just introduce
masses of kmap thrashing crap with no obvious way to fix it. And it
triples the PTE overhead. Maybe it'd work better in conjunction with
shared pagetables.
M.
-
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/