| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Sep 2008 22:18:18 +0100 From: Sitsofe Wheeler <sitsofe@...oo.com> To: linux-kernel@...r.kernel.org Cc: Ingo Molnar <mingo@...e.hu> Subject: How how latent should non-preemptive scheduling be? Hi, I have an EeePC 900 (Intel Celeron 900Mhz) and it seems to be skipping while playing sound through various desktop apps with a 2.6.27rc6 kernel. It is running off an SD card which really shows up slow writes but the sound is seemingly skipping even when ext3 is not being used. When look at latencytop I often see results similar to this: > Cause Maximum Percentage > Scheduler: waiting for cpu 247.2 msec 64.6 % > futex_wait do_futex sys_futex sysenter_do_call 5.0 msec 24.8 % > do_select core_sys_select sys_select sysenter_do_c 4.7 msec 0.7 % > do_sys_poll sys_poll sysenter_do_call 4.5 msec 5.6 % > do_sys_poll sys_ppoll sysenter_do_call 4.2 msec 1.7 % > rt_mutex_timed_lock futex_lock_pi do_futex sys_fut 3.5 msec 0.5 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_re 1.9 msec 1.3 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_bu 1.9 msec 0.4 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_bu 1.9 msec 0.5 % > on acpi_ex_field_datum_io acpi_ex_extract_from_field acpi_ex_read_data_from_field acpi_ex_resolve_node_to_value acpi_ex_resolve_to_va > lue > > > > Process rhythmbox (5694) Total: 358.4 msec > Scheduler: waiting for cpu 221.8 msec 69.9 % > futex_wait do_futex sys_futex sysenter_do_call 4.5 msec 26.3 % > do_sys_poll sys_poll sysenter_do_call 3.8 msec 3.2 % > do_select core_sys_select sys_select sysenter_do_c 1.0 msec 0.4 % > rt_mutex_timed_lock futex_lock_pi do_futex sys_fut 0.2 msec 0.1 % > Cause Maximum Percentage > Scheduler: waiting for cpu 234.8 msec 31.1 % > futex_wait do_futex sys_futex sysenter_do_call 5.0 msec 34.4 % > do_select core_sys_select sys_select sysenter_do_c 5.0 msec 10.3 % > do_sys_poll sys_ppoll sysenter_do_call 5.0 msec 6.2 % > do_sys_poll sys_poll sysenter_do_call 5.0 msec 16.4 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_re 1.9 msec 0.9 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_bu 1.9 msec 0.3 % > msleep acpi_ec_wait acpi_ec_transaction acpi_ec_bu 1.9 msec 0.3 % > blk_execute_rq scsi_execute scsi_execute_req scsi_ 1.0 msec 0.0 % > > > Process firefox-bin (5756) Total: 482.2 msec > Scheduler: waiting for cpu 234.8 msec 95.5 % > do_sys_poll sys_poll sysenter_do_call 4.1 msec 3.5 % > futex_wait do_futex sys_futex sysenter_do_call 3.9 msec 1.0 % > do_select core_sys_select sys_select sysenter_do_c 0.2 msec 0.0 % top seems to show that there is CPU time still available. The kernel is compiled with voluntary preemption, dynticks and a HZ of 1000. Is the scheduler waiting for CPU anything to do with the skips? If so what sort of maximum should I be expecting? If you are listing to music is it expected that you have preemption on? Would preemption even help? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists