[zfs-discuss] Re: A Plea for Help: Thumper/ZFS/NFS/B43

[Alan Romeril]

Hi Ben,
Your sar output shows one core pegged pretty much constantly!  From the Solaris 
Performance and Tools book that SLP state value has "The remainder of important 
events such as disk and network waits. along with other kernel wait 
events..  kernel locks or condition variables also accumilate time in this 
state"

ZFS COUNT
zfs_create 4178
ZFS AVG TIME
zfs_create 71215587
ZFS SUM TIME
zfs_create 297538724997

I think it looks like the system must be spinning in zfs_create(), looking in 
usr/src/uts/common/fs/zfs/zfs_vnops.c there are a couple of places it could 
loop:-

   1129 /*
   1130  * Create a new file object and update the directory
   1131  * to reference it.
   1132  */

   1154 error = dmu_tx_assign(tx, zfsvfs->z_assign);
   1155 if (error) {
   1156 zfs_dirent_unlock(dl);
   1157 if (error == ERESTART &&
   1158 zfsvfs->z_assign == TXG_NOWAIT) {
   1159 dmu_tx_wait(tx);
   1160 dmu_tx_abort(tx);
   1161 goto top;
   1162 }

and

   1201 /*
   1202  * Truncate regular files if requested.
   1203  */
   1204 if ((ZTOV(zp)->v_type == VREG) &&
   1205 (zp->z_phys->zp_size != 0) &&
   1206 (vap->va_mask & AT_SIZE) && (vap->va_size == 0)) {
   1207 error = zfs_freesp(zp, 0, 0, mode, TRUE);
   1208 if (error == ERESTART &&
   1209 zfsvfs->z_assign == TXG_NOWAIT) {
   1210 /* NB: we already did dmu_tx_wait() */
   1211 zfs_dirent_unlock(dl);
   1212 VN_RELE(ZTOV(zp));
   1213 goto top;

I think the snoop would be very useful to pour over.

Cheers,
Alan
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: A Plea for Help: Thumper/ZFS/NFS/B43

[Anton B. Rang]

> I'm still confused though, I believe that locking an adaptive mutex will spin 
> for a short
> period then context switch and so they shouldn't be burning CPU - at least 
> not .4s worth!

An adaptive mutex will spin as long as the thread which holds the mutex is on 
CPU.  If the lock is moderately contended, you can wind up with threads 
spinning for quite a while as ownership of the lock passes from thread to 
thread across CPUs.

Mutexes in Solaris tend to be most useful when they're held for very short 
periods of time; they also work pretty well if the owning thread blocks. If 
somebody is computing for quite a while while holding them (e.g. if 
dnode_next_offset is repeatedly called and is slow), they can waste a lot of 
time on other CPUs. In this case an rwlock usually works better.

Anton
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss