* 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