>> > objrmap does not seem to help. Page clustering might, but is unlikely to
>> > be enabled on the machines which actually care about the overhead.
>>
>> eh? Not sure what you mean by that. It helped massively ...
>> diffprofile from kernbench showed:
>>
>> -4666 -74.9% page_add_rmap
>> -10666 -92.0% page_remove_rmap
>>
>> I'd say that about an 85% reduction in cost is pretty damned fine ;-)
>> And that was about a 20% overall reduction in the system time for the
>> test too ... that was all for partial objrmap (file backed, not anon).
>
> In the test I use (my patch management scripts, which is basically bash
> forking its brains out) objrmap reclaims only 30-50% of the rmap CPU
> overhead.
>
> Maybe you had a very high sharing level.
Not especially, I was running "make -j 32" for that one, which seems like
a fairly small sharing load (though maybe a bit lighter than yours still).
Going to high numbers of tasks will show even more impressive improvements.
"make -j 256" actually looked reasonably similar.
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/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:25 EST