public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* 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

* 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

* 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

* 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