Remove artificial restriction on lio_listio's operation count

[asomers]

Summary

Remove artificial restriction on lio_listio's operation count

In r322258 I made p1003_1b.aio_listio_max a tunable. However, further
investigation shows that there was never any good reason for that limit to
exist in the first place. It's used in two completely different ways:

• To size a UMA zone, which globally limits the number of concurrent aio_suspend calls.

• To artifically limit the number of operations in a single lio_listio call. There doesn't seem to be any memory allocation associated with this limit.

This change does two things:

• Properly names aio_suspend's UMA zone, and sizes it based on a new constant.

• Eliminates the artifical restriction on lio_listio. Instead, lio_listio calls will now be limited by the more generous max_aio_queue_per_proc. The old p1003_1b.aio_listio_max is now an alias for vfs.aio.max_aio_queue_per_proc, so sysconf(3) will still work with _SC_AIO_LISTIO_MAX.

Reported by: bde

[jhb]

sys/kern/vfs_aio.c

1959 ↗

(On Diff #32370)

This should probably honor the max aio queue per proc limit rather than being its own thing.

1970 ↗

(On Diff #32370)

I kind of feel like this shouldn't be a UMA zone at all, but just a plain malloc + free. It's just an array of pointers, not a structure, and will often be variable sized. If you do this, then you can just honor the current max per proc limit above and not have to worry about the fixed size of a UMA zone item.

[asomers]

Respond to jhb's suggestions:

1. Use malloc instead of uma_zalloc for aio_suspend
2. remove the MAX_AIO_SUSPEND constant

[asomers]

Update the man pages too

[asomers]

Sorry I didn't include the man page differences originally. I just realized that they need updating. I also noticed that there are a lot of other man pages that reference preprocessor symbols like IOV_MAX when they should be referencing sysconf/getconf variables like {IOV_MAX} instead. I'll update those separately.