sceKernelCreateThread: optimal priority values
-
- Posts: 339
- Joined: Thu Sep 29, 2005 4:19 pm
sceKernelCreateThread: optimal priority values
How can I determine the optimal priority value for a thread created with sceKernelCreateThread? For example in my app I have a network thread with priority 0x18, a decode thread with 0x16 and a video thread with 0x16. I noticed that the performance of my app can change rather dramatically if I tweak the priority values. So far it has been trial and error, I'm looking for a systematic approach.
Alas I do not think there is really much of a systematic approach you can take to thread priorities, it really depends on the types of work each thread is performing and how resistent they would be to interruptions. It also will depend how they interact with each other.
Based on your example I would probably say that the decode thread is probably doing the most work therefore it probably should have a lower thread priority (i.e. a higher number) than the other two as they are likely to be relatively short lived and reactive. In general I would say anything which tends to go into a wait state often (e.g. IO bound stuff such as a network thread or something limited by the blank interval such as a video thread) would need to be higher priority to ensure that they can react as quickly as possible to the event to prevent stalling the decode too much and go back as quickly as possible to the wait state.
Of course I dont know the exact work your code is doing, so it is hard to say for certain, it probably really is a case of suck it and see. I'll try to remember to add a function to tweak the thread priority from the psplink shell so you can test what works best at runtime :)
Based on your example I would probably say that the decode thread is probably doing the most work therefore it probably should have a lower thread priority (i.e. a higher number) than the other two as they are likely to be relatively short lived and reactive. In general I would say anything which tends to go into a wait state often (e.g. IO bound stuff such as a network thread or something limited by the blank interval such as a video thread) would need to be higher priority to ensure that they can react as quickly as possible to the event to prevent stalling the decode too much and go back as quickly as possible to the wait state.
Of course I dont know the exact work your code is doing, so it is hard to say for certain, it probably really is a case of suck it and see. I'll try to remember to add a function to tweak the thread priority from the psplink shell so you can test what works best at runtime :)
-
- Posts: 339
- Joined: Thu Sep 29, 2005 4:19 pm
-
- Posts: 328
- Joined: Sun Jun 03, 2007 10:05 pm