The AutoStatsTracker is used by various code paths to record operation counters in Top and to set the correct diagnostic information on the operation's CurOp. Amongst its jobs is to determine the profiling level associated with the operation, and set it on the CurOp. Since the profiling level can be configured on a per-database basis, and since this information is stored in-memory inside the catalog subsystem's Database object, this involves acquiring the appropriate MODE_IS intent lock on the database:

https://github.com/mongodb/mongo/blob/9a7cfb73da3a86d1c20f674140f1f908e2bae0c8/src/mongo/db/db_raii.cpp#L62-L65

As implemented, it is possible for this lock acquisition to conflict with parallel oplog batch application on secondary nodes. However, the MODE_IS database lock here is used solely to protect access to DatabaseImpl::_profile. Therefore, there is no need to conflict with batch application. Preventing such lock conflicts could increase throughput of operations that use the AutoStatsTracker. Many operations that use the AutoStatsTracker, such as secondary reads via the find command, are already configured to avoid conflicting with batch application inside AutoGetCollectionForRead:

https://github.com/mongodb/mongo/blob/9a7cfb73da3a86d1c20f674140f1f908e2bae0c8/src/mongo/db/db_raii.cpp#L90-L95

However, there are code paths which use the AutoStatsTracker but never use AutoGetCollectionForRead, causing unnecessary blocking during batch application while attempting to set the profiling level. This was observed in our performance testing infrastructure for the OP_KILL_CURSORS code path.