* RE: [ACPI] acpi_os_queue_for_execution()
@ 2003-01-03 19:00 Grover, Andrew
[not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-01-06 11:44 ` Andrew Morton
0 siblings, 2 replies; 7+ messages in thread
From: Grover, Andrew @ 2003-01-03 19:00 UTC (permalink / raw)
To: Pavel Machek, ACPI mailing list, kernel list
> From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org]
> Acpi seems to create short-lived kernel threads, and I don't quite
> understand why.
>
> In thermal.c
>
>
> tz->timer.data = (unsigned long) tz;
> tz->timer.function = acpi_thermal_run;
> tz->timer.expires = jiffies + (HZ *
> sleep_time) / 1000;
> add_timer(&(tz->timer));
>
> and acpi_thermal_run creates kernel therad that runs
> acpi_thermal_check. Why is not acpi_thermal_check called directly? I
> don't like idea of thread being created every time thermal zone needs
> to be polled...
Are we allowed to block in a timer callback? One of the things
thermal_check does is call a control method, which in turn can be very
slow, sleep, etc., so I'd guess that's why the code tries to execute
things in its own thread.
Regards -- Andy
^ permalink raw reply [flat|nested] 7+ messages in thread[parent not found: <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>]
* Re: [ACPI] acpi_os_queue_for_execution() [not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org> @ 2003-01-04 22:44 ` Matthew Wilcox 2003-01-05 12:23 ` Ingo Oeser 2003-01-06 11:12 ` Pavel Machek 2 siblings, 0 replies; 7+ messages in thread From: Matthew Wilcox @ 2003-01-04 22:44 UTC (permalink / raw) To: Grover, Andrew; +Cc: Pavel Machek, ACPI mailing list, kernel list On Fri, Jan 03, 2003 at 11:00:04AM -0800, Grover, Andrew wrote: > Are we allowed to block in a timer callback? One of the things > thermal_check does is call a control method, which in turn can be very > slow, sleep, etc., so I'd guess that's why the code tries to execute > things in its own thread. timers are run in bottom-half context. no sleeping allowed. if you're going to linux.conf.au, you'll want to attend my talk that deals with exactly this kind of thing ;-) i'll put the paper up on the web in a couple of weeks, after the proceedings are published. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ACPI] acpi_os_queue_for_execution() [not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org> 2003-01-04 22:44 ` Matthew Wilcox @ 2003-01-05 12:23 ` Ingo Oeser 2003-01-06 11:12 ` Pavel Machek 2 siblings, 0 replies; 7+ messages in thread From: Ingo Oeser @ 2003-01-05 12:23 UTC (permalink / raw) To: Grover, Andrew; +Cc: Pavel Machek, ACPI mailing list, kernel list Hi Andrew, On Fri, Jan 03, 2003 at 11:00:04AM -0800, Grover, Andrew wrote: > > From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org] > > Acpi seems to create short-lived kernel threads, and I don't quite > > understand why. [...] > > and acpi_thermal_run creates kernel therad that runs > > acpi_thermal_check. Why is not acpi_thermal_check called directly? I > > don't like idea of thread being created every time thermal zone needs > > to be polled... > > Are we allowed to block in a timer callback? One of the things > thermal_check does is call a control method, which in turn can be very > slow, sleep, etc., so I'd guess that's why the code tries to execute > things in its own thread. No you just have to switch completely to schedule_work() as you do for calls from interrupts. The limitations you mention in osl.c for this function are lifted (look at linux/kernel/workqueue.c) and we have per CPU workqueues now. So no need for this uglification and less code to maintain for you ;-) The short lived threads are not necessary anymore. If this thermal check will happen often an extra permanent thread for this, which is kicked by a timer might be more apropriate here. That thread could be started, once the thermal control is loaded. Regards Ingo Oeser -- Science is what we can tell a computer. Art is everything else. --- D.E.Knuth ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ACPI] acpi_os_queue_for_execution() [not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org> 2003-01-04 22:44 ` Matthew Wilcox 2003-01-05 12:23 ` Ingo Oeser @ 2003-01-06 11:12 ` Pavel Machek 2 siblings, 0 replies; 7+ messages in thread From: Pavel Machek @ 2003-01-06 11:12 UTC (permalink / raw) To: Grover, Andrew; +Cc: ACPI mailing list, kernel list Hi! > > Acpi seems to create short-lived kernel threads, and I don't quite > > understand why. > > > > In thermal.c > > > > > > tz->timer.data = (unsigned long) tz; > > tz->timer.function = acpi_thermal_run; > > tz->timer.expires = jiffies + (HZ * > > sleep_time) / 1000; > > add_timer(&(tz->timer)); > > > > and acpi_thermal_run creates kernel therad that runs > > acpi_thermal_check. Why is not acpi_thermal_check called directly? I > > don't like idea of thread being created every time thermal zone needs > > to be polled... > > Are we allowed to block in a timer callback? One of the things > thermal_check does is call a control method, which in turn can be very > slow, sleep, etc., so I'd guess that's why the code tries to execute > things in its own thread. But... Creating a kernel thread can block, too? [Correct me if I'm wrong, but creating a kernel thread looks like a *lot* of semaphores taken to me]. Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ACPI] acpi_os_queue_for_execution() 2003-01-03 19:00 [ACPI] acpi_os_queue_for_execution() Grover, Andrew [not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org> @ 2003-01-06 11:44 ` Andrew Morton [not found] ` <3E196C17.7D318CAF-LL/9OlyS9hIAvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 7+ messages in thread From: Andrew Morton @ 2003-01-06 11:44 UTC (permalink / raw) To: Grover, Andrew; +Cc: Pavel Machek, ACPI mailing list, kernel list "Grover, Andrew" wrote: > > > From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org] > > Acpi seems to create short-lived kernel threads, and I don't quite > > understand why. > > > > In thermal.c > > > > > > tz->timer.data = (unsigned long) tz; > > tz->timer.function = acpi_thermal_run; > > tz->timer.expires = jiffies + (HZ * > > sleep_time) / 1000; > > add_timer(&(tz->timer)); > > > > and acpi_thermal_run creates kernel therad that runs > > acpi_thermal_check. Why is not acpi_thermal_check called directly? I > > don't like idea of thread being created every time thermal zone needs > > to be polled... > > Are we allowed to block in a timer callback? One of the things > thermal_check does is call a control method, which in turn can be very > slow, sleep, etc., so I'd guess that's why the code tries to execute > things in its own thread. > acpi_thermal_run is doing many sinful things. Blocking memory allocations as well as launching kernel threads from within a timer handler. Converting it to use schedule_work() or schedule_delayed_work() would fix that up. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <3E196C17.7D318CAF-LL/9OlyS9hIAvxtiuMwx3w@public.gmane.org>]
* Re: [ACPI] acpi_os_queue_for_execution() [not found] ` <3E196C17.7D318CAF-LL/9OlyS9hIAvxtiuMwx3w@public.gmane.org> @ 2003-01-06 12:58 ` Andrew McGregor [not found] ` <20150000.1041857884-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Andrew McGregor @ 2003-01-06 12:58 UTC (permalink / raw) To: Andrew Morton, Grover, Andrew Cc: Pavel Machek, ACPI mailing list, kernel list --On Monday, January 06, 2003 03:44:23 -0800 Andrew Morton <akpm-LL/9OlyS9hIAvxtiuMwx3w@public.gmane.org> wrote: > acpi_thermal_run is doing many sinful things. Blocking memory > allocations as well as launching kernel threads from within a > timer handler. > > Converting it to use schedule_work() or schedule_delayed_work() > would fix that up. So *that* is why ACPI kernels are so slow on my laptop (Dell i8k), and make so much heat. I bet one of those threads ends up busy looping because of other brokenness. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20150000.1041857884-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* Re: [ACPI] acpi_os_queue_for_execution() [not found] ` <20150000.1041857884-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> @ 2003-01-06 17:26 ` Faye Pearson 0 siblings, 0 replies; 7+ messages in thread From: Faye Pearson @ 2003-01-06 17:26 UTC (permalink / raw) To: Andrew McGregor Cc: Andrew Morton, Grover, Andrew, Pavel Machek, ACPI mailing list, kernel list Andrew McGregor [andrew-Rd3uoDiDeHXJKwlM9GxbOw@public.gmane.org] wrote: > So *that* is why ACPI kernels are so slow on my laptop (Dell i8k), and make > so much heat. I bet one of those threads ends up busy looping because of > other brokenness. My laptop was a lot happier when I removed the GPE _L00 method from my DSDT which was busylooping sending a processor 0x80 event. Faye -- Faye Pearson, Covert Development ClaraNET Ltd. Tel 020 7903 3000 Familiarity breeds contempt -- and children. -- Mark Twain ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-01-06 17:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-03 19:00 [ACPI] acpi_os_queue_for_execution() Grover, Andrew
[not found] ` <F760B14C9561B941B89469F59BA3A84725A107-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-01-04 22:44 ` Matthew Wilcox
2003-01-05 12:23 ` Ingo Oeser
2003-01-06 11:12 ` Pavel Machek
2003-01-06 11:44 ` Andrew Morton
[not found] ` <3E196C17.7D318CAF-LL/9OlyS9hIAvxtiuMwx3w@public.gmane.org>
2003-01-06 12:58 ` Andrew McGregor
[not found] ` <20150000.1041857884-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2003-01-06 17:26 ` Faye Pearson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox