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

Authored by asomers on Apr 22 2024, 6:06 PM.

Details

Reviewers

markj
imp

Commits

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

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

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 57279
Build 54167: arc lint + arc unit

Event Timeline

asomers created this revision.Apr 22 2024, 6:06 PM

Herald added a subscriber: imp. · View Herald TranscriptApr 22 2024, 6:06 PM

asomers requested review of this revision.Apr 22 2024, 6:06 PM

Harbormaster completed remote builds in B57279: Diff 137502.Apr 22 2024, 6:06 PM

imp accepted this revision.Apr 22 2024, 6:21 PM

This revision is now accepted and ready to land.Apr 22 2024, 6:21 PM

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.

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?

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.

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.