From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>,
rjw@sisk.pl, balbir@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
a.p.zijlstra@chello.nl, shaohua.li@intel.com,
svaidy@linux.vnet.ibm.com
Subject: Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1
Date: Mon, 5 Oct 2009 16:23:12 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0910051614510.3432@localhost.localdomain> (raw)
In-Reply-To: <20091005154021.129a8f9f.akpm@linux-foundation.org>
On Mon, 5 Oct 2009, Andrew Morton wrote:
>
> But it's all too late now, isn't it. This is the first time that
> non-linux-acpi readers knew of the existence of this driver.
Why do people even care? This driver is not going to be used in any
situation where any regular person will _ever_ care. And if you don't
like it, you don't have to enable it at all.
That driver is ACPI-specific, is not very complex, is marked EXPERIMENTAL,
and everybody including Len has said that _if_ the scheduler people can
ever solve it at that level, it would be good. But as it is, it has
NOTHING to do with the scheduler, and why _should_ any non-ACPI people
know about the existence of that driver?
In fact, the only reason the scheduler people even know about it is that
Len at first tried to do something more invasive, and was shot down. Now
it's just a driver, and the scheduler people can _try_ to do it some other
way if they really care, but that's _their_ problem. Not the driver.
In the meantime, I personally suspect we probably never want to even try
to solve it in the scheduler, because why the hell should we care and add
complex logic for something like that? At least not until we end up having
the same issue on some other architecture too, and it turns from a hacky
ACPI thing into something more.
As it is, the driver is entirely self-contained and doesn't affect any
other subsystem.
Linus
next prev parent reply other threads:[~2009-10-05 23:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-03 5:56 [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1 Len Brown
2009-10-03 20:49 ` Rafael J. Wysocki
2009-10-05 3:32 ` Balbir Singh
2009-10-05 5:33 ` Vaidyanathan Srinivasan
2009-10-05 7:15 ` Balbir Singh
2009-10-05 19:59 ` Rafael J. Wysocki
2009-10-05 20:33 ` Balbir Singh
2009-10-05 20:56 ` Linus Torvalds
2009-10-05 21:51 ` Rafael J. Wysocki
2009-10-05 22:17 ` Len Brown
2009-10-05 21:04 ` Andrew Morton
2009-10-05 22:20 ` Len Brown
2009-10-05 22:40 ` Andrew Morton
2009-10-05 23:23 ` Linus Torvalds [this message]
2009-10-06 1:28 ` Len Brown
2009-10-06 9:16 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.01.0910051614510.3432@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=shaohua.li@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox