I would do just those ones. Essentially, dirty nifs run on their own scheduler. If you make every nif dirty, you may artificially slowing down the faster returning calls as they will be scheduled alongside the longer running calls.

From erl_nif — OTP 29.0.2 (erts 17.0.2)

"A NIF that cannot be split and cannot execute in a millisecond or less is called a “dirty NIF”, as it performs work that the ordinary schedulers of the Erlang runtime system cannot handle cleanly. Applications that make use of such functions must indicate to the runtime that the functions are dirty so they can be handled specially. This is handled by executing dirty jobs on a separate set of schedulers called dirty schedulers. A dirty NIF executing on a dirty scheduler does not have the same duration restriction as a normal NIF.

It is important to classify the dirty job correct. An I/O bound job should be classified as such, and a CPU bound job should be classified as such. If you should classify CPU bound jobs as I/O bound jobs, dirty I/O schedulers might starve ordinary schedulers. I/O bound jobs are expected to either block waiting for I/O, and/or spend a limited amount of time moving data."

Dirty NIFs block calling other dirty NIFs. If you have more NIF calls than you have NIF runtimes divided by average length of call, then you will get a traffic jam.