In that case I think you could just use a big enough pool (say 2 * core count) for low priority requests, and do the work directly in the request handler for high priority requests, bypassing the pool.
Reject low priority requests if the pool is full. You can also use s_broker if you want to get fancy and allow some queuing to deal with sudden spikes.
Even if the pool is saturated and CPU usage reaches 100%, the app will stay responsive, since the BEAM context switches very frequently.
