The EVM_NEW_FILE flag is unset if the file already existed at the time of open and this can be checked without looking at i_writecount. Not accessing it reduces traffic on the cacheline during parallel open of the same file and drop the evm_file_release routine from second place to bottom of the profile. Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx> --- The context is that I'm writing a patch which removes one lockref get/put cycle on parallel open. An operational WIP reduces ping-pong in that area and made do_dentry_open skyrocket along with evm_file_release, due to i_writecount access. With the patch they go down again and apparmor takes the rightful first place. The patch accounts for about 5% speed up at 20 cores running open3 from will-it-scale on top of the above wip. (the apparmor + lockref thing really don't scale, that's next) I would provide better measurements, but the wip is not ready (as the description suggests) and I need evm out of the way for the actual patch. security/integrity/evm/evm_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c index 62fe66dd53ce..309630f319e2 100644 --- a/security/integrity/evm/evm_main.c +++ b/security/integrity/evm/evm_main.c @@ -1084,7 +1084,8 @@ static void evm_file_release(struct file *file) if (!S_ISREG(inode->i_mode) || !(mode & FMODE_WRITE)) return; - if (iint && atomic_read(&inode->i_writecount) == 1) + if (iint && iint->flags & EVM_NEW_FILE && + atomic_read(&inode->i_writecount) == 1) iint->flags &= ~EVM_NEW_FILE; } -- 2.43.0
