Hi again, See my comments inline.
On Fri, Mar 30, 2012 at 10:27 PM, Tobias Weingartner <weing...@tepid.org>wrote: > This is one of the better emails on this subject I've seen in a long time. > Very nice to see the amount of work you have put into this so far. If I > may, I'd love to make a couple comments. These are not meant to > discourage you in any way, but comments from the peanut gallery. > Thanks for your review. There is no problem in pointing the problems. This is the reason I had posted, to get more insight of this. > After a brief documentation I can start working on the following goals: > > > > A. Detect how many threads have each core > > - adding a generic way of detecting how many threads each core has > (create > > a map of siblings for example) > > Is this similar to what I was yaking about above? :) > Yes. But here I included the start-up configuration of CPU info and detect if the physical CPU has support for HT and propagate this to the scheduler (as in the project description states: "ground work" ). > > - guard all new added the information regarding HyperThreading. For > this, > > I will add an option (Enable HT) in the config file [5]. > > I'm not 100% sure how the HT stuff affects things today. It used to > be that HT was > definitely about shared resources, and running an "MP" style workload > on an HT cpu > was really not going to get you much. I think that most cpu's today > have much better > HT implementations, and they can largely be treated as a full "MP" > core. Matt may > have some better insights into this though. I think we should keep separate the code that is specific to HT. Here is a matter of design decision. > B. Effective SMT aware scheduling task > > In order to achieve the final goal, I have to make a design of how > > threads will get scheduled. I will have to treat different cases: > > - "passive" scheduling - select a free physical CPU (if available) for > the > > next thread to schedule > > - "active" scheduling - if a physical CPU becomes idle and on another CPU > > are running two threads, migrate one of them on the idle physical cpu > > - what task to get from a list - get the one that was scheduled on that > > domain (physical CPU), no matter on what logical CPU has run before > > - tasks should stick to the same domain (physical CPU) > > In general, I believe that "moving" threads to a new CPU should be > "harder" than > just "Oh, look, a free core, and we have more than 1 thread here, > let's move" type > of heuristic. There should be some sort of hysteresis, or resistance > to this type > of movement, such that we don't end up flip-flopping all the time. > Also, there are > different reasons or goals to scheduling. The effective/best use of > all cpu cores > is one of them. IE: using all the cores as much as possible. Another > is to identify > when cores/resources (such as memory, bus bandwidth, etc) are being too > highly > utilized, and then splitting load. Conversely consolidating when > things "shrink" in > the utilization department. Note, that the first, naiive method of > scheduling will > end up eating battery life on a laptop. You're keeping all the cores > as busy as you > possibly can, while other methods may not be as optimal in terms of cycles > available to compute things, they may significantly change the power > profile of > the machine. > I am aware of the power consumption when always scheduling on an idle physical CPU, instead of a logical. But this is the goal of the project: first use all the physical cores and then start using logical. The flip-flap problem will be solved with one of the things I stated (each thread should stick to its own domain/physical CPU). I certainly don't expect anyone to solve these things all at once, but > it would be > really cool if these things are kept in mind, and the method used to solve > one > item, could be general enough that the basic infrastructure can be used to > solve > the same thing for another goal. In other words, if I wish to create a > "laptop" > scheduler, I should be able to use the same data structures and methods as > your > "high performance" scheduler, but simply change the "logic" part to > suit my goals. > Does that make sense? > Yes it does. Actually as I was studying the linux kernel scheduling there is a sched_smt_power_savings<http://lxr.linux.no/linux+v3.3/+code=sched_smt_power_savings> options that control the behaviour of the scheduler (it is configurable through procfs from userspace). Thanks for your feedback, Mihai
