[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: Rene Gollent <anevilyak@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 20 Feb 2019 09:48:37 -0500
On Wed, Feb 20, 2019 at 9:41 AM waddlesplash <waddlesplash@xxxxxxxxx> wrote:
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
I'm not sure how that example contradicts what Axel said. Pinning a
thread, as its name implies, does nothing more than lock its execution
to only occurring on the current CPU until it's unpinned again (c.f.
http://xref.plausible.coop/source/xref/haiku/src/system/kernel/scheduler/scheduler.cpp#107
). This is necessary in e.g. the VM code since it may be manipulating
the per-CPU TLB, which would obviously be problematic if the thread is
rescheduled onto another CPU in the middle of the process.
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.
Pinning the thread does not prevent it from being context switched,
that's never been the case. AFAIK, the only thing that can cause the
latter is if interrupts are disabled, as the scheduler's timer
interrupt will obviously not fire in that circumstance. In your VM
example, Flush() is only ever called with the map locked, so a context
switch isn't an issue, as anyone else attempting to access the map
will block on the lock until the thread handling the modification is
done.
Regards,
Rene
Other related posts:
