On 1 Jun 2017, at 7:41, Jeff Layton wrote:
On Thu, 2017-06-01 at 10:05 +0800, kernel test robot wrote:
Greeting,
FYI, we noticed a -14.1% regression of will-it-scale.per_process_ops
due to commit:
commit: 9d21d181d06acab9a8e80eac2ec4eed77b656793 ("fs/locks: Set
fl_nspid at file_lock allocation")
url:
https://github.com/0day-ci/linux/commits/Benjamin-Coddington/fs-locks-Alloc-file_lock-where-practical/20170527-050700
Ouch, that's a rather nasty performance hit. In hindsight, maybe we
shouldn't move those off the stack after all? Heck, if it's that
significant, maybe we should move the F_SETLK callers to allocate
these
on the stack as well?
We can do that. But, I think this is picking up the
locks_mandatory_area()
allocation which is now removed. The attached config has
CONFIG_MANDATORY_FILE_LOCKING=y, so there's allocation on every
read/write.
Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
