Re: 2.5.68-mm2

["Martin J. Bligh" <mbligh@aracnet.com>]

>> > . I got tired of the objrmap code going BUG under stress, so it is now in
>> >   disgrace in the experimental/ directory.
>> 
>> Any chance of some more info on that? BUG at what point in the code,
>> and with what test to reproduce?
> 
> A bash-shared-mapping (from ext3 CVS) will quickly knock it over.  It gets
> its PageAnon/page->mapping state tangled up.

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>