On Tue, May 15, 2007 at 08:44:19AM -0400, shivers_at_ccs.neu.edu wrote:
> It is spinning right now -- it is morning and I opened up my laptop after
> a night of suspension. Here's codacon's current output:
...
>     up lambda.csail.mit.edu ( 08:23:02 )
...
>     BeginStatusWalk [27693] ( 08:35:28 )
>        [0, 28366, 0, 0] [28365] ( 08:35:28 )
...
>     EndStatusWalk [27693] ( 08:43:23 )
>        [28366, 0, 0, 0] [28365, 28369, 28369] [1, 28370, 475.4] ( 08:43:23 )
...
> Does that help?

It does narrow it down quite a bit. It is not related to object
demotion but the cache revalidation / hoarding.

First it makes sure we have valid attributes for all cached objects.
As we are not seeing any getattr or validateattr RPC2 calls, they must
all be valid. Of course we are iterating through the complete list of
cached objects, but this is O(n) and even for 30K objects should be
reasonably efficient.

This is followed by a second phase where the hoard contexts are checked,
we walk all hoard bindings and check if all objects still have the right
hoard priority assigned to them. As hoard bindings are name based this
involves lookup of the path name for each object and then checking if
the object has been assigned the correct hoard priority values. This is
pretty complex code, so it is most likely where we are using 100% CPU.

Jan