On Mon, 31 Jan 2000, Horst von Brand wrote:
> Marco Colombo <marco@esi.it> said:
>
> [...]
>
> > In other words, I won't call an application that has both high
> > switch rate and causes a long RQ "well designed, well tuned".
> > I can hardly think of such an application which has a good cache
> > behaviour at the same time (that's my impression).
> >
> > So I think that an application that has both high switch rate and
> > long RQ is NOT "well designed, well tuned", and you should optimize it.
>
> This might be a legacy application that isn't worth the massive work of
> rewriting, so tune & optimize is out. Question then becomes: How common
> and/or important is this kind of stuff?
I'll answer with a question:
How important can it be, if even its authors or users don't think
it's worth the optimization effort?
This legacy application (before your message, focus was partly on Java
applications, which are not 'legacy', BTW), which has a sub-optimal design,
runs sub-optimally on the current kernel. Its developers don't care
(or have no time to "waste") optimizing it. Should kernel developers do
(or have they time)? Developers time is scarce everywhere...
And for them, Davide kindly provided an useful patch. So if you have to
run that application you have to pay the little price of running a
non vanilla kernel. I don't see nothing wrong with that.
Of course, if after discussing scheduler issues we manage to integrate
Davide's proposal in a way that has no loss for the normal case, we'll
have a better kernel. And we'll thank Davide for starting all this.
> --
> Horst von Brand vonbrand@sleipnir.valparaiso.cl
> Casilla 9G, Viņa del Mar, Chile +56 32 672616
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
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 Feb 07 2000 - 21:00:07 EST