On Mon, 5 Oct 2009 21:59:24 +0200 "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > > > Signed-off-by: Shaohua Li <shaohua.li@xxxxxxxxx> > > > NACKed-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> > > > Cc: Vaidyanathan Srinivasan <svaidy@xxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> > > > > This is a first a patch with a NACKed-by, could we please have more > > discussion on the proposed design. > > This thing has already been merged, it appears: > > commit 8e0af5141ab950b78b3ebbfaded5439dcf8b3a8d > Author: Shaohua Li <shaohua.li@xxxxxxxxx> > Date: Mon Jul 27 18:11:02 2009 -0400 > > ACPI: create Processor Aggregator Device driver > > and it looks like a total breakage of rules to me. To me also. I'm not a great believer in "rules". They're only guidelines based on past experience and an expectation that prior experience is a predictor of future outcomes. Sometimes, in some cases that prediction breaks down, so we should ignore the "rules". But this does not appear to be such a case. The driver was merged over Peter's strenuous and reasonable-sounding objections. Partly because of: On Fri, 26 Jun 2009 12:46:53 -0400 (EDT) Len Brown <lenb@xxxxxxxxxx> wrote: > ... > 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. Problem is, that plan doesn't work. If in 2.6.33 we add the new scheduler capabilities and then convert this driver to utilise them then the enterprise releases don't really have a backported driver any more. They own some special thing which was cherrypicked in a mid-development stage from 2.6.32. And future enhancement or fixing of that driver is not applicable to the enterprise kernel's version. So a large part of the reason for preferring to use backported mainline features will be invalidated. All that being said, I don't see a lot of gain in reverting the driver now. From the mainline kernel's POV we make the scheduler changes, alter the driver and then proceed happily. The thus-stranded enterprise kernel people are then somewhat screwed, but what can we do? Apart from asking "please don't do this again". Technical question: the overall feature, which I'd describe as "shutting down CPUs when an external agent tells us the thermal/electrical/other load is too high" is not at all specific to the x86 CPU. Should the code have been designed in such a way as to permit other architectures to play? -- 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
