Re: How how latent should non-preemptive scheduling be?

[Sitsofe Wheeler]

Sitsofe Wheeler wrote:
> Ingo when you were asking for the ftrace report I presume that would be 
> for a non preempt kernel (as a preemptive one only showed a very worst 
> latency of 19657 us in one exceptional case)?

With a non preempt kernel I found the logs would simply become too big 
without filtering. On Peter's suggestion I used the following to remove 
the most frequently called functions:

echo acpi_os_release_object > set_ftrace_notrace && echo kmem_cache_* >> 
set_ftrace_notrace && echo acpi_ut_* >> set_ftrace_notrace

By doing counts across multiple runs I would say that the most 
frequently called functions are the following (in most frequently called 
order). The counts are definitely approximate but are reasonable 
relative to each other.

 475325 acpi_os_release_object (acpi_ut_delete_generic_state)
 406895 kmem_cache_free (acpi_os_release_object)
 402838 kmem_cache_alloc (acpi_ut_create_generic_state)
 132968 acpi_ut_update_ref_count (acpi_ut_update_object_reference)
 131041 acpi_ut_pop_generic_state (acpi_ut_update_object_reference)
 131036 acpi_ut_delete_generic_state (acpi_ut_update_object_reference)
 131025 acpi_ut_create_generic_state (acpi_ut_create_update_state)
 131023 acpi_ut_create_update_state_and_push 
(acpi_ut_update_object_reference)
 131020 acpi_ut_create_update_state (acpi_ut_create_update_state_and_push)
 131018 acpi_ut_push_generic_state (acpi_ut_create_update_state_and_push)
  60147 acpi_ns_get_next_node (acpi_ns_delete_namespace_by_owner)
  28974 acpi_ns_get_next_valid_node (acpi_ns_get_next_node)

Logs with the filtering on can be seen here (15Mbytes decompressed each):
http://sucs.org/~sits/test/eeepc-debug/20080923/latency_trace.gz
http://sucs.org/~sits/test/eeepc-debug/20080923/trace.txt.gz

It looks like lots of acpi state is created and deleted...

--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/