vfs_acl_xattr and Linux memory fragmentation
Volker.Lendecke at SerNet.DE
Thu Apr 13 08:53:10 UTC 2017
On Thu, Apr 13, 2017 at 11:40:49AM +0300, Uri Simchoni wrote:
> My thinking was that trying 2K and 8K could very well lead to
> accomplishing the task with way more than 2 system calls. There's always
> the option of passing 0 as size to get actual size, then call again with
> the buffer - two system calls.
> But I can add those steps too - I don't have any field-gathered
> information to support this or that strategy, they all have their
> strengths and weaknesses (for example, maybe there are less objects in
> the 8K pool, so it's likelier to be depleted with many concurrent
> users). Ultimately, it's a kernel issue and has been fixed in the kernel
> (don't know specifics of distros).
> What I think we should keep is that the initial allocation is 1K,
> because that preserves the user-mode behavior for the majority of cases.
Then what about starting with 4k, covering 99.9%. If that fails we're
in the slow path. There we could easily take 2 more syscalls, one to
get the real size. This is racy, because between getting the size and
doing the real getxattr call the size could increase, but that should
be rare enough.
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
Samba eXPerience 2017, Hotel Freizeit In
2nd-4th of May 2017, http://sambaXP.org
More information about the samba-technical