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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID:  <48D1741A.7010508@yahoo.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ