Re: objrmap and vmtruncate

[Martin J. Bligh]

>> > The first test has 100 tasks, each of which has 100 vma's.  The 100 processes
>> > modify their 100 vma's in a linear walk.  Total working set is 240MB
>> > (slightly more than is available).
>> > 
>> > 	./rmap-test -l -i 10 -n 100 -s 600 -t 100 foo
>> > 
>> > 2.5.66-mm4:
>> > 	15.76s user 86.91s system 33% cpu 5:05.07 total
>> > 2.5.66-mm4+objrmap:
>> > 	23.07s user 1143.26s system 87% cpu 22:09.81 total
>> > 2.4.21-pre5aa2:
>> > 	14.91s user 75.30s system 24% cpu 6:15.84 total
>> 
>> Isn't the intent to use sys_remap_file_pages for these sort of workloads
>> anyway? In which case partial objrmap = rmap for these tests, so we're
>> still OK?
>> 
> 
> remap_file_pages() would work OK for this, yes.  Bit sad that an application
> which runs OK on 2.4 would need recoding to work acceptably under 2.5 though.

You mean like trying to run Oracle Apps or something? ;-)

5000 tasks, 2Gb shmem segment = 10Gb of PTE chains (I think).
In ZONE_NORMAL.
Somehow.

Both regular rmap and partial objrmap have their corner cases. Both are
fairly easily avoidable. Both may require some app tweaks. I'd argue
that partial objrmap's bad cases are actually more obscure. And it does
better in the common case ... I think that's important.

regular rmap + shared pagetables is more workable than without.

M.