public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* acpi_battery_init() boot speed
@ 2010-12-15  8:13 Len Brown
  2010-12-15  8:15 ` Len Brown
  2010-12-15 11:00 ` Arjan van de Ven
  0 siblings, 2 replies; 8+ messages in thread
From: Len Brown @ 2010-12-15  8:13 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-acpi

Hi Arjan,
I hoped that the test patch below would help acpi_battery_init()
on machines where it runs a lot of AML.  I have a lenovo s10-3
where it was taking 900ms, and this patch seemed to reduce
it to 600ms.  However, I measured again and it seems to have
gone _up_ to 1300ms - so perhaps there is some other factor
determining how long that routine is taking?

-Len

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 65b25a3..4658f61 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -271,7 +271,7 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 		/*
 		* ioremap checks to ensure this is in reserved space
 		*/
-		return ioremap((unsigned long)phys, size);
+		return ioremap_cache((unsigned long)phys, size);
 	else
 		return __acpi_map_table((unsigned long)phys, size);
 }

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-15  8:13 acpi_battery_init() boot speed Len Brown
@ 2010-12-15  8:15 ` Len Brown
  2010-12-15 11:00 ` Arjan van de Ven
  1 sibling, 0 replies; 8+ messages in thread
From: Len Brown @ 2010-12-15  8:15 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-acpi


On Wed, 15 Dec 2010, Len Brown wrote:

> Hi Arjan,
> I hoped that the test patch below would help acpi_battery_init()
> on machines where it runs a lot of AML.  I have a lenovo s10-3
> where it was taking 900ms, and this patch seemed to reduce
> it to 600ms.  However, I measured again and it seems to have
> gone _up_ to 1300ms - so perhaps there is some other factor
> determining how long that routine is taking?

Oh, I should mention that this was vs 2.6.36.stable
and measured by enabling "initcall_debug" and seeing how
long it took for the routine to return.  bootchart.pl
shows that acpi_battery_init is being done in an async thread.

> -Len
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 65b25a3..4658f61 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -271,7 +271,7 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  		/*
>  		* ioremap checks to ensure this is in reserved space
>  		*/
> -		return ioremap((unsigned long)phys, size);
> +		return ioremap_cache((unsigned long)phys, size);
>  	else
>  		return __acpi_map_table((unsigned long)phys, size);
>  }
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-15  8:13 acpi_battery_init() boot speed Len Brown
  2010-12-15  8:15 ` Len Brown
@ 2010-12-15 11:00 ` Arjan van de Ven
  2010-12-15 20:27   ` Len Brown
  2010-12-17  8:46   ` Len Brown
  1 sibling, 2 replies; 8+ messages in thread
From: Arjan van de Ven @ 2010-12-15 11:00 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

On Wed, 15 Dec 2010 03:13:50 -0500 (EST)
Len Brown <lenb@kernel.org> wrote:

> Hi Arjan,
> I hoped that the test patch below would help acpi_battery_init()
> on machines where it runs a lot of AML.  I have a lenovo s10-3
> where it was taking 900ms, and this patch seemed to reduce
> it to 600ms.  However, I measured again and it seems to have
> gone _up_ to 1300ms - so perhaps there is some other factor
> determining how long that routine is taking?

that's still a long time (we boot all other drivers including KMS in
0.5 seconds combined)

wonder if this stuff is polling some battery property ?
(like discharge rate or something)

wonder if the code could do just enough to register the device, and
do everything else in the background?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-15 11:00 ` Arjan van de Ven
@ 2010-12-15 20:27   ` Len Brown
  2010-12-16  4:58     ` Arjan van de Ven
  2010-12-17  8:46   ` Len Brown
  1 sibling, 1 reply; 8+ messages in thread
From: Len Brown @ 2010-12-15 20:27 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-acpi


> wonder if this stuff is polling some battery property ?
> (like discharge rate or something)

Is there a simple way to get a profile that starts when
acpi_battery_init() is called and ends when it returns?

Note that acpi_battery_init() is not 900ms on all boxes --
I had to poke around to find a slow one.  My arrandale
laptop runs acpi_battery_init in 71 ms.

thanks,
-Len



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-15 20:27   ` Len Brown
@ 2010-12-16  4:58     ` Arjan van de Ven
  2010-12-17  4:31       ` Len Brown
  0 siblings, 1 reply; 8+ messages in thread
From: Arjan van de Ven @ 2010-12-16  4:58 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

On Wed, 15 Dec 2010 15:27:44 -0500 (EST)
Len Brown <lenb@kernel.org> wrote:

> 
> > wonder if this stuff is polling some battery property ?
> > (like discharge rate or something)
> 
> Is there a simple way to get a profile that starts when
> acpi_battery_init() is called and ends when it returns?
> 
> Note that acpi_battery_init() is not 900ms on all boxes --
> I had to poke around to find a slow one.  My arrandale
> laptop runs acpi_battery_init in 71 ms.

make it a module, and run "perf top" while in an other terminal you do

while :; do modprobe acpi_battery ; rmmod acpi_battery  ; done



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-16  4:58     ` Arjan van de Ven
@ 2010-12-17  4:31       ` Len Brown
  0 siblings, 0 replies; 8+ messages in thread
From: Len Brown @ 2010-12-17  4:31 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-acpi


> make it a module, and run "perf top" while in an other terminal you do
> 
> while :; do modprobe acpi_battery ; rmmod acpi_battery  ; done

----------------------------------------------------------------------
   PerfTop:     747 irqs/sec  kernel:94.5%  exact:  0.0% [1000Hz cycles],  
(all, 2 CPUs)
----------------------------------------------------------------------

             samples  pcnt function            DSO
             _______ _____ ___________________ _______________________

             2502.00 28.4% intel_idle          [kernel.kallsyms]      
              802.00  9.1% acpi_os_read_port   [kernel.kallsyms]      
              735.00  8.4% read_hpet           [kernel.kallsyms]      
              559.00  6.4% check_poison_obj    [kernel.kallsyms]      
              286.00  3.3% acpi_ec_gpe_handler [kernel.kallsyms]      
              208.00  2.4% cache_free_debugche [kernel.kallsyms]      
              200.00  2.3% cache_alloc_debugch [kernel.kallsyms]      
              169.00  1.9% kmem_cache_alloc    [kernel.kallsyms]      
              138.00  1.6% acpi_debug_print    [kernel.kallsyms]      
               90.00  1.0% hpet_next_event     [kernel.kallsyms]      
               88.00  1.0% kmem_cache_free     [kernel.kallsyms]      
               83.00  0.9% acpi_os_write_port  [kernel.kallsyms]      
               74.00  0.8% acpi_ps_parse_loop  [kernel.kallsyms]      
               72.00  0.8% find_busiest_group  [kernel.kallsyms]      
               72.00  0.8% schedule            [kernel.kallsyms]      
               58.00  0.7% _raw_spin_lock_irqs [kernel.kallsyms]      
               58.00  0.7% acpi_ps_get_opcode_ [kernel.kallsyms]      
               56.00  0.6% advance_transaction [kernel.kallsyms]      
               54.00  0.6% menu_select         [kernel.kallsyms]      
               52.00  0.6% __might_sleep       [kernel.kallsyms]      
               47.00  0.5% ktime_get           [kernel.kallsyms]      
               41.00  0.5% __virt_addr_valid   [kernel.kallsyms]      
               38.00  0.4% start_transaction   [kernel.kallsyms]      
               38.00  0.4% acpi_ec_transaction [kernel.kallsyms]      
               36.00  0.4% dbg_redzone2        [kernel.kallsyms]      
               36.00  0.4% _raw_spin_unlock_ir [kernel.kallsyms]      
               35.00  0.4% tick_nohz_stop_sche [kernel.kallsyms]      
               33.00  0.4% acpi_ps_complete_op [kernel.kallsyms]      
               32.00  0.4% sched_clock         [kernel.kallsyms]      
               32.00  0.4% getnstimeofday      [kernel.kallsyms]      
               32.00  0.4% __switch_to         [kernel.kallsyms]      
               31.00  0.4% acpi_ds_exec_end_op [kernel.kallsyms]      
               31.00  0.4% ec_check_ibf0       [kernel.kallsyms]      
               31.00  0.4% irq_entries_start   [kernel.kallsyms]      
               30.00  0.3% acpi_hw_read        [kernel.kallsyms]      
               30.00  0.3% acpi_ev_gpe_detect  [kernel.kallsyms]      
               29.00  0.3% acpi_ec_transaction [kernel.kallsyms]      
               28.00  0.3% acpi_ut_update_obje [kernel.kallsyms]      
               27.00  0.3% acpi_ut_update_ref_ [kernel.kallsyms]      
               26.00  0.3% acpi_hw_validate_io [kernel.kallsyms]      
               25.00  0.3% acpi_hw_read_port   [kernel.kallsyms]      
               24.00  0.3% find_symbol_in_sect [kernel.kallsyms]      
               24.00  0.3% __GI___strcmp_ssse3 /lib64/libc-2.12.90.so 
               23.00  0.3% __phys_addr         [kernel.kallsyms]      
               23.00  0.3% acpi_ex_resolve_ope [kernel.kallsyms]      
               21.00  0.2% select_task_rq_fair [kernel.kallsyms]      
               21.00  0.2% acpi_hw_validate_re [kernel.kallsyms]      
               21.00  0.2% enqueue_task_fair   [kernel.kallsyms]      
               20.00  0.2% cpuidle_idle_call   [kernel.kallsyms]      
               19.00  0.2% find_next_bit       [kernel.kallsyms]      
               19.00  0.2% ns_to_timeval       [kernel.kallsyms]      
               19.00  0.2% _raw_spin_lock      [kernel.kallsyms]      
               19.00  0.2% acpi_ut_allocate_ob [kernel.kallsyms]      
               19.00  0.2% acpi_ut_create_gene [kernel.kallsyms]      
               19.00  0.2% g_hash_table_lookup libglib-2.0.so.0.2600.0
               18.00  0.2% sched_clock_local   [kernel.kallsyms] 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-15 11:00 ` Arjan van de Ven
  2010-12-15 20:27   ` Len Brown
@ 2010-12-17  8:46   ` Len Brown
  2010-12-17 16:02     ` Arjan van de Ven
  1 sibling, 1 reply; 8+ messages in thread
From: Len Brown @ 2010-12-17  8:46 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-acpi

> wonder if the code could do just enough to register the device, and
> do everything else in the background?

or do it later on demand...

This patch reduces acpi_battery_init() time
on the Lenovo S10-3 from 901,603 usec to 657 usec.

AFAICT, the battery monitor etc worked fine.

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 95649d3..79e8ba3 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -943,7 +943,6 @@ static int acpi_battery_add(struct acpi_device *device)
 	if (ACPI_SUCCESS(acpi_get_handle(battery->device->handle,
 			"_BIX", &handle)))
 		set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
-	acpi_battery_update(battery);
 #ifdef CONFIG_ACPI_PROCFS_POWER
 	result = acpi_battery_add_fs(device);
 #endif




^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: acpi_battery_init() boot speed
  2010-12-17  8:46   ` Len Brown
@ 2010-12-17 16:02     ` Arjan van de Ven
  0 siblings, 0 replies; 8+ messages in thread
From: Arjan van de Ven @ 2010-12-17 16:02 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi

On Fri, 17 Dec 2010 03:46:12 -0500 (EST)
Len Brown <lenb@kernel.org> wrote:

> > wonder if the code could do just enough to register the device, and
> > do everything else in the background?
> 
> or do it later on demand...

that makes complete sense...

but you can even just do that async.. to cut down the time of first
use....

if you want I can propose a patch for that based on the patch below...
> 
> This patch reduces acpi_battery_init() time
> on the Lenovo S10-3 from 901,603 usec to 657 usec.
> 
> AFAICT, the battery monitor etc worked fine.
> 
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 95649d3..79e8ba3 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -943,7 +943,6 @@ static int acpi_battery_add(struct acpi_device
> *device) if (ACPI_SUCCESS(acpi_get_handle(battery->device->handle,
>  			"_BIX", &handle)))
>  		set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
> -	acpi_battery_update(battery);
>  #ifdef CONFIG_ACPI_PROCFS_POWER
>  	result = acpi_battery_add_fs(device);
>  #endif
> 
> 
> 


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-12-17 15:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-15  8:13 acpi_battery_init() boot speed Len Brown
2010-12-15  8:15 ` Len Brown
2010-12-15 11:00 ` Arjan van de Ven
2010-12-15 20:27   ` Len Brown
2010-12-16  4:58     ` Arjan van de Ven
2010-12-17  4:31       ` Len Brown
2010-12-17  8:46   ` Len Brown
2010-12-17 16:02     ` Arjan van de Ven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox