geli: add a read-only kern.geom.eli.use_uma_bytes sysctl

[asomers]

Summary

It reports the value of the g_eli_alloc_sz variable. Allocations of
this size or less will use UMA. Larger allocations will use malloc.
Since malloc is slower, it is useful for users to know this variable so
they can avoid such allocations. For example, ZFS users can set
vfs.zfs.vdev.aggregation_limit to this value.

MFC after: 1 week
Sponsored by: Axcient

[markj]

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

[asomers]

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

I was planning to follow up with a new tip in fortune(6) and at https://wiki.freebsd.org/ZFSTuningGuide . Do you think that would be sufficient or would you like geli(8) too?

[markj]

In D44904#1023722, @asomers wrote:

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

I was planning to follow up with a new tip in fortune(6) and at https://wiki.freebsd.org/ZFSTuningGuide . Do you think that would be sufficient or would you like geli(8) too?

I'm skeptical that fortune(6) is good place to document anything performance-related. ZFSTuningGuide seems like a good place, but I think geli.8 is the right document for this kind of knowledge. There are other performance considerations relating to GELI that have nothing to do with ZFS (GELI's thread-per-CPU-per-volume behaviour for instance) that would also belong in a "PERFORMANCE CONSIDERATIONS" section in geli.8.

[asomers]

In D44904#1023723, @markj wrote:

In D44904#1023722, @asomers wrote:

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

I was planning to follow up with a new tip in fortune(6) and at https://wiki.freebsd.org/ZFSTuningGuide . Do you think that would be sufficient or would you like geli(8) too?

I'm skeptical that fortune(6) is good place to document anything performance-related. ZFSTuningGuide seems like a good place, but I think geli.8 is the right document for this kind of knowledge. There are other performance considerations relating to GELI that have nothing to do with ZFS (GELI's thread-per-CPU-per-volume behaviour for instance) that would also belong in a "PERFORMANCE CONSIDERATIONS" section in geli.8.

Ok. I'll make a PR there.