arc4random_buf_large() is not exported as an API; this is intentional.

If you do arc4random_buf_large() for a small buffer size, say 8, you
are not winning the output performance vs output quality vs system
interactiveness tradeoff in any way.  It is a loss in all respects.

2048 was estimated as a knee where it the setup cost for a seperate
RC4 is cheap enough so that PRNG data can be created for independent
kernel threads without contention/holding of the mutex.

This mechanism was invented to improving interactive performance.  However
it is still expensive.

[ message continues ]

Right. the arc4random_buf_large() mechanism will still get used, though, by
anyone who calls arc4random_buf() with a big enough request, correct? And
the setup time in this case will also be affected by the multiplier we
choose for dumping initial keystream.

I think I need to code up some test cases...

-kj

[ message continues ]