[OpenAFS-devel] Re: progress... sortof...

[Neulinger, Nathan]

> I'd be very surprised if the call/return you incur by not=20
> inlining these
> calls is amounting to any noticeable amount of overhead...

Maybe not... but if you take a look at some of the call counts with
xstat_cm_test on some of my machines - even if the improvement is
negligable, shrinking the code path on something executed so many times
has got to have some improvement. The below numbers are from one of my
machines that has been up for 4 days.=20

           1456177 afs_open
           1543772 osi_Free
           1554317 osi_Alloc
           1601603 afs_close
           2225818 osi_Read
           2468900 afs_newslot
           2468900 FixupBucket
           2901946 osi_Close
           2901947 osi_UFSOpen
           2998982 osi_FreeLargeSpace
           2998983 osi_AllocLargeSpace
           5288368 afs_inactive
           6788037 DVOffset
           8112868 afs_GetVCache
          10254372 afs_lookup
          11085536 afs_GetDCache
          11833633 afs_UFSGetDSlot
          13718420 afs_FindVCache
          13754548 afs_CheckCode
          30356351 afs_PutDCache
          33980702 DRelease
          34441831 DRead
          53935533 afs_GetVolume
          59459894 afs_PutVCache
          60593994 afs_access
          71869043 afs_AccessOK
          71869043 afs_GetAccessBits
         122447789 afs_get_pag_from_groups
         131328561 afs_InitReq
         131397954 PagInCred
         135742910 afs_CopyOutAttrs

> > Also seems like there is some serious room for optimization of the
> > xcache lock when doing lots of putvcache ops in a row... Another
> > time...
>=20
> Similarly, under GLOCK, obtaining and releasing locks is just a simple
> increment or decrement operation..  And infact, these lock calls _are_
> being inlined, although I'd rather they were real functions (this may
> actually speed up things, on modern CPUs).

-- Nathan