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

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-prev] [day] [month] [year] [list]

Message-ID: <48D74027.7020708@yahoo.com>
Date:	Mon, 22 Sep 2008 07:50:15 +0100
From:	Sitsofe Wheeler <sitsofe@...oo.com>
To:	Matt Keenan <tank.en.mate@...il.com>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: How how latent should non-preemptive scheduling be?

Matt Keenan wrote:
> If you use ALSA you could write a custom .asoundrc file and increase
> ALSA's default buffer size, this gives the hardware a longer buffer to
> play which may work around the problem. This used to do the trick for me
> with the old scheduler with slow machines. Not a fix but if nothing else
> works...

In all fairness turning on preemption also helps (I don't hear any drops 
or see any stalls once it's on) but I'm trying to work out if this is an 
underlying problem that can be fixed (and then there is the case of the 
default desktop distros).

-- 
Sitsofe | http://sucs.org/~sits/
--
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/