[Gluster-devel] Shared resource pool for libgfapi
Jeff Darcy
jdarcy at redhat.com
Mon Jun 8 11:51:07 UTC 2015
> Every resource(thread, mem pools) is associated with glusterfs_ctx,
> hence as the ctxs in the process grows the resource utilization also
> grows (most of it being unused). This mostly is an issue with any
> libgfapi application: USS, NFS Ganesha, Samba, vdsm, qemu. It is
> normal in any of the libgfapi application to have multiple
> mounts(ctxs) in the same process, we have seen the number of threads
> scale from 10s-100s in these applications.
> Solution:
> ======
> Have a shared resource pool, threads and mem pools. Since they are
> shared
Looking at it from a different perspective...
As I understand it, the purpose of glusterfs_ctx is to be a container
for these resources. Therefore, the problem is not that the resources
aren't shared within a context but that the contexts aren't shared
among glfs objects. This happens because we unconditionally call
glusterfs_ctx_new from within glfs_new. To be honest, this looks a
bit like rushed code to me - a TODO in early development that never
got DONE later. Perhaps the right thing to do is to let glfs_new
share an existing glusterfs_ctx instead of always creating a new one.
It would even be possible to make this the default behavior (so that
existing apps can benefit without change) but it might be better for
it to be a new call. As a potential future enhancement, we could
provide granular control over which resources are shared and which
are private, much like clone(2) does with threads.
More information about the Gluster-devel
mailing list