Whamcloud - gitweb
LU-9417 mdc: excessive memory consumption by the xattr cache 23/28223/5
authorAndrew Perepechko <andrew.perepechko@seagate.com>
Fri, 28 Apr 2017 17:20:06 +0000 (20:20 +0300)
committerJohn L. Hammond <john.hammond@intel.com>
Wed, 11 Oct 2017 18:57:29 +0000 (18:57 +0000)
commitd737064716efd624ccca3f401e89a98b1767651f
treef1ce8b2f96ddfed66d740165fd042763f60621fa
parent4044521770d2258ee0fa998d77830183155e2532
LU-9417 mdc: excessive memory consumption by the xattr cache

The refill operation of the xattr cache does not know the
reply size in advance, so it makes a guess based on
the maxeasize value returned by the MDS.

In practice, it allocates 16 KiB for the common case and
4 MiB for the large xattr case. However, a typical reply
is just a few hundred bytes. Even worse, RHEL6 has a very
bad vmalloc()/vfree() design with global locks.

If we follow the conservative approach, we can prepare a
single memory page for the reply. It is large enough for
any reasonable xattr set and, at the same time, it does
not require multiple page memory reclaim, which can be
costly.

If, for a specific file, the reply is larger than a single
page, the client is prepared to handle that and will fall back
to non-cached xattr code. Indeed, if this happens often and
xattrs are often used to store large values, it makes sense to
disable the xattr cache at all since it wasn't designed for
such [mis]use.

Lustre-change: https://review.whamcloud.com/26887
Lustre-commit: 94f080b395d6517e8da06a945bb10b0bfe69ad78

Change-Id: I98d97ffea5c83bccbc9f254717af8d2c0ac4d77f
Signed-off-by: Andrew Perepechko <andrew.perepechko@seagate.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Ben Evans <bevans@cray.com>
Signed-off-by: Minh Diep <minh.diep@intel.com>
Reviewed-on: https://review.whamcloud.com/28223
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
lustre/mdc/mdc_locks.c