staging: lustre: mdc: cl_default_mds_easize not refreshed
authorNed Bass <bass6@llnl.gov>
Sun, 18 Sep 2016 20:38:56 +0000 (16:38 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 19 Sep 2016 08:08:22 +0000 (10:08 +0200)
commit8ed62e91c4adf3f37c665d1d892aa17dc7150ab7
tree97eb0bad8fa5196ae8e213ca16981794bdd0c948
parent60b65afb700626f0fe43589138c8ca9ac460d634
staging: lustre: mdc: cl_default_mds_easize not refreshed

The client_obd::cl_default_mds_easize field should track the largest
observed EA size advertised by the MDT, subject to a reasonable upper
bound. The MDC uses cl_default_mds_easize to calculate the initial
size of request buffers.  The default value should be small enough to
avoid wasted memory and excessive use of vmalloc(), yet large enough
to accommodate the common use case.

In the current code, the default value is only updated if
client_obd::cl_max_mds_easize is strictly less than
mdt_body::mbo_max_mdsize. This condition is almost never met, because
client_obd::cl_max_mds_easize is computed at client mount-time based
on the number of OSTs in the filesystem, so the MDT won't ever observe
and advertise an EA size larger than that.

As a result, client_obd::cl_default_mds_easize indefinitely retains
its initial value, which is computed at client mount-time based on
the filesystem's default stripe width. Any getattr() requests for
widely striped files will consequently allocate a request buffer
that is too small, forcing reallocations on both the client and
server side. To avoid this, update client_obd::cl_default_mds_easize
independently of the value of client_obd::cl_max_mds_easize.

In addition, this patch includes these changes:

 - Add comments to the client_obd structure to clarify what the
   cl_{default,max}_mds_{cookie,ea}size values mean.

 - Prevent mdc_get_info() from storing uninitialized data in
   client_obd::cl_max_mds_cookiesize.

 - Use 4096 as an upper bound for the default values.  The former
   bound of PAGE_CACHE_SIZE is too large on 64k-page platforms
   (i.e. PPC), so it fails to prevent the vmalloc() spinlock
   contention described in LU-3338. The new value was chosen to
   be large enough to accommodate common use cases while staying
   well below the 16k threshold at which allocations start using
   vmalloc().

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Kyle Blatter <kyleblatter@llnl.gov>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5549
Reviewed-on: http://review.whamcloud.com/11614
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/staging/lustre/lustre/include/lustre_mdc.h
drivers/staging/lustre/lustre/include/obd.h
drivers/staging/lustre/lustre/llite/llite_lib.c