> > > Hmm, would fully idling a socket not be more efficient (throughput wise) > > > than forcing everybody into P states? > > > > Nope. > > > > Low Frequency Mode (LFM), aka Pn - the deepest P-state, > > is the lowest energy/instruction because it is this highest > > frequency available at the lowest voltage that can still > > retire instructions. > > This is true if you want to retire instructions. But in case you want > to stop retiring instructions and hold cores in idle, then idling > complete package will be more efficient right? No. Efficiency = Work/Energy Thus if Work=0, then Efficiency=0. > Atleast you will need > to idle all the sibling threads at the same time to save power in > a core. Yes. Both HT siblings need to be idled in a core for it to significantly reduce power. > > That is why it is the first method used -- it returns the > > highest power_savings/performance_impact. > > Depending on what is running in the system, force idling cores may > help reduce average power as compared to running all cores at lowest > P-state. The workloads that we've measured show that reducing p-states has a smaller impact to average performance than idling cores. > > The power and thermal monitoring are out-of-band in the platform, > > so Linux is not (currently) part of a closed control loop. > > However, Linux is part of the control, and the loop is indeed closed:-) > > The more we could include Linux in the control loop, we can better > react to the situation with least performance impact. Some vendors prever to control things in-band, some prefer to control them out-of-band. I'm agnostic. Vendors should be free to provision, and customers should be free to run systems in the way that they choose. > > > The thing I'm thinking off is vaidy's load-balancer changes that take an > > > overload packing argument. > > > > > > If we can couple that to the ACPI driver in a closed feedback loop we > > > have automagic tuning. > > > > I think that those changes are probably fancier than we need for > > this simple mechanism right now -- though if they ended up being different > > ways to use the same code in the long run, that would be fine. > > I agree that the load-balancer approach is more complex and has > challenges. The main challenge of the load-balancer approach is that it it not available to be shipped today. > But it does have long term benefits because we can > utilise the scheduler's knowledge of system topology and current > system load to arrive at what is best. > > > Some integration with P states might be interesting to think about. But > > > as it stands getting that load-balancer placement stuff fixed seems like > > > enough fun ;-) > > > > I think that we already have an issue with scheduler vs P-states, > > as the scheduler is handing out buckets of time assuming that > > they are all equal. However, a high-frequency bucket is more valuable > > than a low frequency bucket. So probably the scheduler should be tracking > > cycles rather than time... > > > > But that is independent of the forced-idle thread issue at hand. > > > > We'd like to ship the forced-idle thread as a self-contained driver, > > if possilbe. Because that would enable us to easily back-port it > > to some enterprise releases that want the feature. So if we can > > implement this such that it is functional with existing scheduler > > facilities, that would be get us by. If the scheduler evolves > > and provides a more optimal mechanism in the future, then that is > > great, as long as we don't have to wait for that to provide > > the basic version of the feature. > > ok, so if you want a solution that would work on older distros also, > then your choices are limited. For backports, perhaps this module > will work, but should not be a baseline solution for future. The current driver receives the number of cpu's to idle from the system, and spawns that many forced-idle threads. When Linux has a method better than spawning forced-idle-threads, we'll gladly update the driver to us it... thanks, -Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
