On Fri, 28 Jan 2000, water modem wrote:
> FYI:
> In the telcom world we try to drive our processors at
> about 75%. Cache hits are real important here.
> In our Tandem based Call Processing machines
> we typically run with 10 to 14 MB L2 cache and even
> after tuning near everything still get much better
> improvements just keeping something in cache compared
> to major rewrites on a functional basis.
> It is kind of interesting that we see the following repeated
> on various platforms (includeing embedded) under various workloads.
> 1/3 resources (time&space) for OS
> 1/3 resources (applications written by us)
> 1/3 resources for 1 or 2 purchased drivers or applications
> {^^^always the best but most complictated target for improvement}
I can agree with You about cache optimization, but the fact is that the patch,
for RQ < limit introduced only a memory load ( 4 bytes ) and memory write ( 4
bytes ).
It is the wrong way to get off the patch ( benchmarks first, cache issues
after, ...) that driven me to this kind of defence of the patch.
As I've stated into the message opening this thread I'm all but sure that
the RQs that makes the patch to boost, will be usual in real world.
As I've reported to Linus, Alan and Ingo, the better way to reject the patch
is the one that state that the code bloat ( 200 lines ) is not sustained
by a real gain under normal loads.
Cheers,
Davide.
-- All this stuff is IMVHO- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:22 EST