> This sounds more like a micro benchmark tool, which is a good start, but the
> real problem with VM optimizations is, that they have to take into account
> real world load and especially user experience.
>
The tool is a micro test and benchmark tool, true. It is known and noted
in the documentation that this won't take overall system performance into
account. Fortunatly there is a number of existing userland tools out there
like lmbench that provide that type of information and there is a number
of subjective reports available from users regarding interactivity.
> applications like "connected to gui". This feature would need a test then,
> which is no usual micro benchmark.
>
That type of information is different to what VM Regress aims to provide.
VM Regress is aimed at providing performance and test data on individual
parts of the VM.
> hot code path, but it does not help much the developers in the problem of
> simulating workload and measuring the interactive and real throughput.
>
> But perhaps you can take this into account?
>
I have taken it into account and decided after some thought that overall
performance and throughput is not the place for a micro tool like VM
Regress and more the domain of a userland test suite.
I am more interested in answering questions like
o Does subsystem X still work after changes made to it?
o How well does subsystem X perform?
o How long does it take to find pages to swap out?
o How much overhead is introduced by feature Y?
o What does my process space look like after vmscan does it's work?
For example, in time, it'll be able to tell exactly how well rmap is
performing and compare it to a VM without rmap in terms of "how long it
took to find a page to replace" and "what did the address space look like
after kswapd worked". I should be able to show that rmap kept the correct
pages in memory for instance where as an overall benchmarking tool is
going to tell me nothing new. Used in combination with a profiling tool
like oprofile, I should be able to get very specific performance data that
I suspect will be useful to developers and to a much lesser extent, users.
I am making a persumption that if it can be shown that each individual
component is working and performs well, then overall performance should
improve.
-- Mel Gorman MSc Student, University of Limerick http://www.csn.ul.ie/~mel- 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/