[haiku-commits] Re: haiku: hrev52902 - in src: add-ons/kernel/busses/usb add-ons/kernel/bus_managers/usb system/kernel system/kernel/arch/x86
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 20 Feb 2019 09:41:17 -0500
On Wed, Feb 20, 2019, 9:15 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx wrote
Not sure if I follow this logic. When I pin a thread to a specific CPU,
all I want to achieve is to have it run only on that specific CPU.
Uh, that's not my understanding of what "pinned" does. See e.g. its usage
in x86 VM code:
http://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/paging/X86VMTranslationMap.cpp#99
Obviously it would be a problem if that code suddenly was moved to a
different CPU during execution, but it also clearly would be a problem if
someone context-switched during its execution, too.
However, looking at the scheduler code, I guess I'm not so sure that's what
actually happens. It appears pinned threads can actually yield under a
variety of circumstances, though ultimately I'm not sure I understand how
"effective priority" is computed there, so maybe they are truly pinned.
I don't see any other way to block context switches without disabling
interrupts though; so are the functions linked above (and actually pretty
much all the arch VM ones) wrong? Or should the scheduler indeed not ever
context switch threads? We definitely should have a way to prevent context
switches without disabling interrupts, and I though this was it.
-waddlesplash
Other related posts:
