RE: [ACPI] acpi_os_queue_for_execution()

RE: [ACPI] acpi_os_queue_for_execution()

[Grover, Andrew]

> From: Pavel Machek [mailto:pavel@ucw.cz] 
> 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

Re: [ACPI] acpi_os_queue_for_execution()

[Matthew Wilcox]

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

Re: [ACPI] acpi_os_queue_for_execution()

[Ingo Oeser]

Hi Andrew,

On Fri, Jan 03, 2003 at 11:00:04AM -0800, Grover, Andrew wrote:
> > From: Pavel Machek [mailto:pavel@ucw.cz] 
> > 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

Re: [ACPI] acpi_os_queue_for_execution()

[Pavel Machek]

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.

Re: [ACPI] acpi_os_queue_for_execution()

[Andrew Morton]

"Grover, Andrew" wrote:
> 
> > From: Pavel Machek [mailto:pavel@ucw.cz]
> > 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.

Re: [ACPI] acpi_os_queue_for_execution()

[Andrew McGregor]

--On Monday, January 06, 2003 03:44:23 -0800 Andrew Morton <akpm@digeo.com> 
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.

Re: [ACPI] acpi_os_queue_for_execution()

[Faye Pearson]

Andrew McGregor [andrew@indranet.co.nz] 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

Re: [ACPI] acpi_os_queue_for_execution()

[peter.holmes]

>> Andrew McGregor [andrew@indranet.co.nz] 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.

> Faye Pearson [faye@clara.net] wrote:
> My laptop was a lot happier when I removed the GPE _L00 method from my
> DSDT which was busylooping sending a processor 0x80 event.

As a relative newcomer to LINUX quite a lot of it is a foreign language,
(no awful pun intended).  I've been around electronics and computers for
quite a few years now.  So would you be so kind as to explain just what
is "GPE_L00" and "DSDT".  And just how we remove the salient part?
I have a new Acer Aspire 1304LC which I could cook an egg on.
Windoze(2K & XP Pro) don't generate anything like so much warmth.

Peter

Re: [ACPI] acpi_os_queue_for_execution()

[Faye Pearson]

peter.holmes@fopet-esl.com [peter.holmes@fopet-esl.com] wrote:
> As a relative newcomer to LINUX quite a lot of it is a foreign language,
> (no awful pun intended).  I've been around electronics and computers for
> quite a few years now.  So would you be so kind as to explain just what
> is "GPE_L00" and "DSDT".  And just how we remove the salient part?
> I have a new Acer Aspire 1304LC which I could cook an egg on.
> Windoze(2K & XP Pro) don't generate anything like so much warmth.

These terms have nothing to do with linux, they're ACPI things from
within the BIOS.  the GPE is a General Purpose Event I believe.  The
_L00 event seems to be an event which is generated if the machine gets
too hot - It may be called something different on a different
manufacturer's BIOS.

What you need to do is run an ACPI enabled kernel and dump the
/proc/acpi/dsdt to a file (cat /proc/acpi/dsdt > mydsdt.aml).  You can't
read this directly as it is in a compiled form.  You need to disassemble
it and you do that with the iasl assembler/disassembler you can get from
Intel's instantly available technology pages.
(http://www.intel.com/technology/iapc/acpi/downloads.htm)

Once you have it disassembled, try "compiling" it straight away and you
will probably find that there are errors and warnings.  Check the acpi
mailing list archives for details on how to fix these.

Once you have it working, compile it into the kernel - how to do this is
covered in the archives as well.  Booting with this kernel should make
your acpi work much better.  If it doesn't solve your heating problem
then if you put your disassembled and original dsdt on the web somewhere
and post a message asking for help, with links to these files on the
acpi list then you are likely to get some good assistance.

It is definitely worthwhile, my laptop now runs about 99% of the time
with no fan - showing it's much cooler.

The page with my efforts on for the Compaq Presario 2701EA is
http://dude.noc.clara.net/~faye/

Good luck.


Faye

-- 
Faye Pearson,
Covert Development
ClaraNET Ltd.       Tel 020 7903 3000

You don't move to Edina, you achieve Edina.
		-- Guindon