On Sun, Apr 26, 2009 at 11:04 PM, <olafBuddenhagen@gmx.net>
Yeah, while rpctracing something else, I was also surprised about the
On Sun, Apr 26, 2009 at 10:01:56PM +0100, Da Zheng wrote:
> I logged all RPCs and tried to analyze them. (antrik, I was wrong.
> There aren't 100, 000 RPCs. The number of RPCs to the Mach during the
> subhurd booting is about 20,000 - 60,000). I found something
> abnormal, but I am not sure if it should be considered as errors.
high number of failing RPCs -- this seems to be quite common throughout
Note that such errors are not necessary bugs. As long as the error
return is handled appropriately, the code can be still perfectly
It would be an interesting task though to investigate such failing RPCs,
and see where they come from. Some of these might indeed indicate
non-obvious bugs, that cause various kinds of problems. Also, there
might be some room for optimization: if the caller checks for certain
parameters that will obviously cause an RPC to fail up front, it would
avoid the unnecessary roundtrip...
If we trace RPCs, we should trace all of them, not only the failed ones, so we might be able to do some optimization. I really doubt if it is necessary to have so many RPCs.
But I wonder how you trace the source of these RPCs.
From the logging of 'boot', I can know what are the target tasks but I cannot tell where are the RPCs from, because a task can send the RPC on the behalf of another task.