Re: PUFFS performance on netbsd-6
hi, Hi I am runnning my usual perfuse test case on netbsd-6: building the netbsd tree. Performances are much lower than on netbsd-5. A quick dump of FUSE operations shows that the thing spends most of its time on lookups. It will exhibit behavior like this: LOOKUP a LOOKUP a/b LOOKUP a/b/c LOOKUP a/b/c/d GETATTR a/b/c/d LOOKUP a LOOKUP a/b LOOKUP a/b/c LOOKUP a/b/c/e GETATTR a/b/c/e It seems that while the kernel still knows about a/b/c (it was not reclaimed), it still have to lookup from the root. Is that on purpose? If it is, then what is the rationale? if your filesystem is not using namecache and the application is using full paths to look up files, the trace looks normal. otherwise, it looks weird. YAMAMOTO Takashi I have not yet tested on -current. -- Emmanuel Dreyfus m...@netbsd.org
Re: PUFFS performance on netbsd-6
hi, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: if your filesystem is not using namecache and the application is using full paths to look up files, the trace looks normal. otherwise, it looks weird. I only have PUFFS_KFLAG_NOCACHE_NAME set when calling puffs_init On netbsd-5, the kernel never looked up a node twice without reclaiming in between. You could have either this behavior (I ommit lookup and reclaim on x/y and x/z for the sake of clarity): LOOKUP x GETATTR x/y RECLAIM x LOOKUP x GETATTR x/z RECLAIM x Or that one: LOOKUP x GETATTR x/y GETATTR x/z RECLAIM x But never this new behavior I observe on netbsd-6: LOOKUP x GETATTR x/y LOOKUP x GETATTR x/z RECLAIM x RECLAIM x the behaviour on netbsd-6 is what i expect with PUFFS_KFLAG_NOCACHE_NAME. probably the flag is broken on netbsd-5? having said that, the two consecutive RECLAIMs for the same node seems strange. it could be a bug in cookie - vnode lookup code, which produces duplicated vnodes for a cookie. YAMAMOTO Takashi -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: PUFFS performance on netbsd-6
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: LOOKUP x GETATTR x/y LOOKUP x GETATTR x/z RECLAIM x RECLAIM x the behaviour on netbsd-6 is what i expect with PUFFS_KFLAG_NOCACHE_NAME. probably the flag is broken on netbsd-5? If netbsd-6 behavvior is right, then indeed the flag was broken on netbsd-5. Unfortnately this makes netbsd-6 much more slower. I did not run hard tests, but I would estimates it as 10 times slower. FUSE LOOKUPs return a TTL for a node. I guess it is time to modify the PUFFS interface and kernel lookup code so that the kernel can be made aware of that information. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
