Hi Xuehan Perhaps granularity of DBObjectMap::header_lock is a bit coarse, but it doesn't matter. Threads will be waiting on cache_lock if DBObjectMap::header_lock is removed roughly. So overhead is brought by lookup and adding header to DBObjectMap::caches. thanks ivan from eisoo On Tue, Nov 28, 2017 at 5:51 PM, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: > > Hi, everone. > > Recently, we did some stress tests on mds. We found that, when doing > file creation test, the mdlog trim operations are very slow. After > doing some debugging, we found that this could be due to execution of > the OSD's filestore theads being forced to be nearly sequential. This > can be found out in our result of gdbprof probing, which is attached > with this email. In the gdbprof result, we can see that the most time > consuming work of the filestore threads is the sizing of > DBObjectMap::caches, and the reason of sequential execution of > filestore threads is the locking of DBObjectMap::header_lock. > > After reading the corresponding source code, we found that > MapHeaderLock is already doing the mutual exclusion of access of the > omap object header. It seems that the locking of > DBObjectMap::header_lock is not very necessary, or at least, it's not > needed when adding the header to DBObjectMap::caches, which would lead > to the sizing of the cache. > > Is this right? -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
