Re: A different performance measure

Hi,

Mike A Larson wrote:
>
> perf1 attempts to measure the time to do a context switch + the time to
> send a message that doesn't contain any data. Now, the difference between
> the 21 us number and the 75 us number is awfully big. Is the 54 us
> difference totally due to the messaging overhead? Or perhaps the
> perf1/sched_yield() measuring something different that the old perf1?

Well, at least part of the difference is that with perf1 we enter kernel
space 3 times as opposed to 2 for sched_yield(). In addition there's extra
overhead since sched_yield() is really sched_op() called with a single
parameter, whereas msg send, receive and reply take 2 each. Then we also
have to look at the message mappings done within the kernel and the memory
allocations used to manage these. Certainly one of the points I've looked
at this week was the malloc work since these involve a fair amount of work
deciding on which memory bucket to use. I think this is certainly something
worthy of some speedup work - if we look at the debug version of malloc we
already tell the kernel malloc which data we're allocating so maybe this can
be used as a speedup hint.

I think the main thing is that I've found no real design flaws, and that >
100% speedup is really lots of little things. Now I know how much overhead
the messaging is placing on us it becomes easier to look for optimisations.

I think the other point is that whilst context switch times are important we
shouldn't loose sight of what they really give us - perhaps now would be a
good time to port something like iozone and see how fast something more
tangible really is.

                        Regards,
                        Dave
Received on Sat Jan 21 07:37:10 1995