[haiku-bugs] Re: [Haiku] #1069: Create thread scheduler with CPU affinity
- From: "Duggan" <trac@xxxxxxxxxxxx>
- Date: Fri, 21 Oct 2011 21:41:25 -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 Duggan):
Thanks alot for the input! In response:
* Some changes (like Thread::affinity_hard) are preparatory steps for
future work. I'll look into those functions you mention as I haven't run
across them myself yet and get rid of the flag once I understand it.
* I considered the issues with modifying get_current_cpuid() but didn't
want to screw too much up at first, I'll replace it in the next patch.
* As far as round_to_pwr_of_2(), it's inelegant but it's really only a
hack... I don't think it's needed (at this point) for anything more than
8 bits.
* I'll change the macro names... I wasn't sure if it was a big deal or
not. I was more interested in fewer changes at the time heh.
* I'll change the display_topology() function next patch too.
* I guess I'll go back and undo some of the coding style stuff keeping it
purely functional (fixing things in my code of course).
As far as the future work:
* I'll have to look into that more... It's nothing I've committed to at
this point but I see more benefit in locking only the queues that are
being modified at the time versus all queues causing other processors to
block even if they're not working with the same queues. Would it be
possible to simply not lock it when the scheduler is entered then? I
haven't looked extensively at the overall scheduling system but focused
primarily on the scheduler itself.
* I bet that would be alot of work, but there might be a way to work
around it that isn't too involved so it can be removed post-R1, keeping
only the dynamic array. I'm not that concerned with it right now, maybe
later. Since the constant is only used for declaring array sizes and one
loop (which isn't even necessary) I don't think it would make that big of
an impact at least in the scheduler since no where else (in the scheduler)
are we iterating through unused items. I could always just replace those
arrays with dynamic ones and be done with it.
* I considered that at first but thought it would end up being easier just
to do it this way at first. I'm considering replacing the queues with
trees, but if I do, that would likely be the last thing I do.
Again this was just an intermediate patch and any more feedback like this
on this and future patches would be greatly appreciated.
Thank you very much!
--
Ticket URL: <http://dev.haiku-os.org/ticket/1069#comment:10>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
