You make a very good point!

Since I am not familiar enough with the many details of the NetBSD
kernel and the changes with UBC etc. I have taken a "black box" approach.

I agree, memcpy() is stable and I doubt there is anything that can
be done to squeeze any more speed out of it.

As Chuck pointed out, with an application like bonnie as the load,
memcpy() is likely to be the dominant consumer of CPU time.

So my approach is not to improve memcpy() but to eliminate unnecessary
calls.

I'm sure it has been well understood for some time now that kernels
spend too much of their time copying data round and if it can be
avoided, this is a big win.

In my ignorance, I had hoped that eliminating about 40% of the calls
to memcpy() I was seeing in my profiling would be a good thing.

As I now know, and should have known better, gprof averages total
assigned time to all calls, and a function like memcpy() has a huge
variation in CPU time-consumption depending on usage.

So I apologize for my novice enthusiasm that lead me down a blind alley.

I'll keep poking around.  Maybe I'll find something else that does
make a difference B^)

Cheers,

-- Ken

Toru Nishimura wrote:
> 
> I'm skeptical since the small code fragment around there has been
> ralatively stable for long time.  According to the figures you
> posted a while ago, NetBSD/pmax kernel consumes CPU time much more
> than it used to be.  The CPU time consumption was increased by
> codes which has been added or structural changes in NetBSD kernel.
> So, it'd rather better to pursue them than optimizing microtime()
> or memcpy() themselves.
> 
> -nisimura