[haiku-bugs] Re: [Haiku] #1069: Create thread scheduler with CPU affinity
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Fri, 21 Oct 2011 10:17:39 -0000
#1069: Create thread scheduler with CPU affinity
-----------------------------+---------------------------
Reporter: axeld | Owner: meianoite
Type: enhancement | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/pre-alpha1
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
-----------------------------+---------------------------
Comment (by bonefish):
Great to see someone taking interest in this stuff!
I haven't really read through the code. Just a few remarks:
- You introduce Thread::affinity_hard, but never use it. And yes
`pinned_to_cpu`, if > 0 means the thread will only be scheduled on the CPU
it ran previously. There are symmetric functions to pin/unpin a thread.
The member being an int32 allows them to be nested.
- `get_current_cpuid_ex()`: The usual function naming on Haiku in this
case would be `get_current_cpuid_etc()`. If you specify a default value
for the new parameter anyway, there's no reason not just to extend
`get_current_cpuid()` instead, though.
- `round_to_pwr_of_2()`: Name should be "..._power_...". The function
should be static. It's a bit ugly that it only works for number <= 128. It
isn't performance critical in this case, so there's no reason not to
implement it generally.
- `RunQueue()` and `RunQueueSize()` should follow the macro naming scheme
(all upper case, words separated by underscore).
- `display_topology()`: Should be static. A better name would be
`dump_topology()`.
- It's generally preferable not to mix coding style changes with
functional changes.
Regarding your future work suggestions:
- You can't do away with the scheduler lock. It is needed outside the
scheduler to implement locking primitives.
- The most important change in the kernel regarding scheduling is to get
rid of `B_MAX_CPU_COUNT`. It's currently 8 which is already insufficient
for some of todays desktop machines. Given the general direction the CPU
manufactures are headed just raising the number (which is a binary
compatibility concern, BTW) wouldn't help for long either. The CPU array
needs to be allocated dynamically. Getting rid of the static
`B_MAX_CPU_COUNT` in kernel and drivers is probably quite a bit of work.
- I wonder, if a tree/forest representation of the CPU structure would be
better than the extra fields you added to `cpu_ent`.
--
Ticket URL: <http://dev.haiku-os.org/ticket/1069#comment:9>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
