A different metric for scheduler optimisation

[Davide Libenzi]

On Sun, 30 Jan 2000, Jamie Lokier wrote:
> Davide Libenzi wrote:
> > Anyway consider the faster switching app that I know ( this can be an FTP
> > server for example ):
> > 
> > char buffer[N];
> > for(;;)
> > {
> > 	read(infd, buffer, N);
> > 	write(outfd, buffer, N);
> > }
> > 
> > for N = 1 this app "can switch very fast" and touch very few bytes, and this
> > seems to confirm my hypothesise.
> 
> Well, well...  this one only switches when it blocks waiting for data or
> waiting for the output queue to flush.
> 
> And when it does that, it _isn't_ on the run queue!
> 
> In other words, run several of these in parallel and you will still get
> a very low run queue length.

Jamie, We're not speaking of speaking about RQ now ;)
This thread born from a my consideration that high switching tasks "probably"
does not have a great cache trashing due to the fact that since they run a very
short time they have a lower "probability" to touch RAM locations.

Steve have said that may be true the contrary and I tried to give an
explanation of my point of view in a previous message :

<PREVMSG>
We can stay here speaking about my hypothesise for a while, You showing me an
app that confirm Your hypothesise and me one that confirm the mine.
I've included the word "probability" meaning that can exist app types that get
off my hypothesise.
Anyway consider the faster switching app that I know ( this can be an FTP
server for example ):

char buffer[N];

for(;;)
{
        read(infd, buffer, N);
        write(outfd, buffer, N);
}

for N = 1 this app "can switch very fast" and touch very few bytes, and this
seems to confirm my hypothesise.

What if N = 1000000 ?
If N = 1000000 it flush out every single bit of cache, but ..., but can this app
switch very fast ?
What is the "time footprint" of this app ?
The time footprint of this app can be defined as the average time taken by the
instruction pointer ( EIP for Intel ) to reach the same value.
The pattern of this app is :
RCW
R = read
C = compute ( 0 )
R = write
and the entire pattern must be used to define the time footprint.
A necessary condition to make a app switch fast, not one time but continuosly,
is to have a low time footprint that this app don't have ( for that N ).
And the time footprint of this app is inverse proportional to the average speed
of devices used to transfer the data.
More if You spawn M copies of this app, the switching rate is upper limited by
the lower throwput of the used devices.
</PREVMSG>

That's all.
Until now ;)


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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/