I think the point is you don’t. As I understand it you create a thread and let the OS know how high priority it is, and certain boundaries that you promise not to break (with JUCE you achieve this by calling startRealtimeThread() and supplying the RealtimeThreadOptions to specify the boundaries). Then based on that, other competing priorities, and how well behaved the code in your thread is, the OS decides if it will be placed on a P-core or E-core as well as when to wake the thread. If you additionally join an audio workgroup I suspect it will help the scheduler to decide when to wake your thread to complete any work.
To be clear I can’t say the above with any real authority but that’s how I understand it works.
In experiments I did with the HighResolutionTimer I found when the thread was upgraded to a realtime thread the performance was exceptional and it was very hard to downgrade the performance which suggests to me that not only was it running on a P-core but actually even when I pushed it well outside the boundaries I specified for the thread it remained on one without any noticeable penalty. However, your experience may differ.