(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-05-15 10:44:23