Bug#266905: marked as done (RFP: kernel-patch-voluntary-preempt -- lower kernel latency by voluntary preemption)
Your message dated Thu, 22 Sep 2005 17:18:28 -0600
with message-id <E1EIaKi-0006yS-00@merkel.debian.org>
and subject line WNPP bug closing
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 19 Aug 2004 16:28:36 +0000
>From jordens@debian.org Thu Aug 19 09:28:36 2004
Return-path: <jordens@debian.org>
Received: from wiggis.ethz.ch [129.132.86.197] (postfix)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BxpmG-0004SM-00; Thu, 19 Aug 2004 09:28:36 -0700
Received: from wiggis1.ethz.ch (wiggis1.ethz.ch [192.168.127.2])
by wiggis.ethz.ch (Postfix) with ESMTP
id 945E7340C3; Thu, 19 Aug 2004 18:28:34 +0200 (CEST)
Received: from kermit (pD952E8E5.dip.t-dialin.net [217.82.232.229])
(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
(No client certificate requested)
by wiggis.ethz.ch (Postfix) with ESMTP
id 88BF8340AF; Thu, 19 Aug 2004 18:28:33 +0200 (CEST)
Received: by kermit (Postfix, from userid 1000)
id 68E8980F5; Thu, 19 Aug 2004 18:27:09 +0200 (CEST)
Date: Thu, 19 Aug 2004 18:27:09 +0200
From: Robert Jordens <jordens@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Cc: debian-multimedia@lists.debian.org,
Guenter Geiger <geiger@debian.org>,
Florian Schmidt <mista.tapas@gmx.net>
Subject: RFP: kernel-patch-voluntary-preempt -- lower kernel latency by voluntary preemption
Message-ID: <20040819162708.GA25801@rjo.dnsalias.org>
Mail-Followup-To: Robert Jordens <jordens@debian.org>,
Debian Bug Tracking System <submit@bugs.debian.org>,
debian-multimedia@lists.debian.org,
Guenter Geiger <geiger@debian.org>,
Florian Schmidt <mista.tapas@gmx.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
X-Reportbug-Version: 2.63
X-GPG-Fingerprint: 1024D/E02FEF11:F01946CCF910B59289E8D6341D28E4BFE02FEF11
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new at phys.ethz.ch
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Package: wnpp
Severity: wishlist
Hi debian-multimedia!
Who is interested in packaging this? I can't do it because I only have
my powerpc to test on which voluntary-preempt is not yet available for.
I know Guenter already did realtime-lsm (hint..). Someone from Agnula?
Thanks.
Robert.
Package name : kernel-patch-voluntary-preempt
Version : 2.6.8.1-P4
Upstream Author : Ingo Molnar <mingo@elte.hu>
URL : http://people.redhat.com/mingo/voluntary-preempt/
License : GPL
Description : lower kernel latency by voluntary preemption
From <http://people.redhat.com/mingo/voluntary-preempt/>:
as most of you are probably aware of it, there have been complaints on
lkml that the 2.6 kernel is not suitable for serious audio work due to
high scheduling latencies (e.g. the Jackit people complained). I took a
look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50 m=
sec
(!) can be easily triggered using common workloads, on fast 2GHz+ x86
system - even when using the fully preemptible kernel!
to solve this problem, Arjan van de Ven and I went over various kernel
functions to determine their preemptability and we re-created from
scratch a patch that is equivalent in performance to the 2.4 lowlatency
patches but is different in design, impact and approach:
http://redhat.com/~mingo/voluntary-preempt/
(Note to kernel patch reviewers: the split voluntary_resched type of
APIs, the feature #ifdefs and runtime flags are temporary and were
only introduced to enable a easy benchmarking/comparisons. I'll split
this up into small pieces and drop the conditional stuff/ifdefs once
there's testing feedback and actual audio users had their say!)
unlike the lowlatency patches, this patch doesn't add a lot of new
scheduling points to the source code, it rather reuses a rich but
currently inactive set of scheduling points that already exist in the
2.6 tree: the might_sleep() debugging checks. Any code point that does
might_sleep() is in fact ready to sleep at that point. So the patch
activates these debugging checks to be scheduling points. This reduces
complexity and impact quite significantly.
but even using these (over one hundred) might_sleep() points there were
still a number of latency sources in the kernel - we identified and
fixed them by hand, either via additional might_sleep() checks, or via
explicit rescheduling points. Sometimes lock-break was necessary as
well.
as a practical goal, this patch aims to fix all latency sources that
generate higher than ~1 msec latencies. We'd love to learn about
workloads that still cause audio skipping even with this patch applied,
but i've been unable to generate any load that creates higher than 1msec
latencies. (not counting driver initialization routines.)
this patch is also more configurable than the 2.4 lowlatency patches
were: there's a .config option to enable voluntary preemption, and there
are runtime /proc/sys knobs and boot-time flags to turn voluntary
preemption (CONFIG_VOLUNTARY_PREEMPT) and kernel preemption
(CONFIG_PREEMPT) on/off:
# turn on/off voluntary preemption (if CONFIG_VOLUNTARY_PREEMPT)
echo 1 > /proc/sys/kernel/voluntary_preemption
echo 0 > /proc/sys/kernel/voluntary_preemption
# turn on/off the preemptible kernel feature (if CONFIG_PREEMPT)
/proc/sys/kernel/kernel_preemption
/proc/sys/kernel/kernel_preemption
the 'voluntary-preemption=3D0/1' and 'kernel-preemption=3D0/1' boot opt=
ions
can be used to control these flags at boot-time.
all 4 combinations make sense if both CONFIG_PREEMPT and
CONFIG_VOLUNTARY_PREEMPT are enabled - great for performance/latency
testing and comparisons.
The stock 2.6 kernel is equivalent to:
voluntary_preemption:0 kernel_preemption:0
the 2.6 kernel with voluntary kernel preemption is equivalent to:
voluntary_preemption:1 kernel_preemption:0
the 2.6 kernel with preemptible kernel enabled is:
voluntary_preemption:0 kernel_preemption:1
and the preemptible kernel enhanced with additional lock-breaks is=20
enabled via:
voluntary_preemption:1 kernel_preemption:1
it is safe to change these flags anytime.
The patch is against 2.6.7-bk20, and it also includes fixes for kernel
bugs that were uncovered while developing this patch. While it works for
me, be careful when using this patch!
Testreports, comments, suggestions are more than welcome,
Ingo
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (300, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-rj1
Locale: LANG=3Den_US.UTF-8, LC_CTYPE=3Den_US.UTF-8
--=20
WYSIWYG:
What You See Is What You Get.
--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBJNTcHSjkv+Av7xERAmNJAJwO+O5Z3YYgnsmKj70IKPy+EvoX2wCfY4Dw
Cr0cIAkfr6fCQbrrekxag44=
=pOEW
-----END PGP SIGNATURE-----
--6TrnltStXW4iwmi0--
---------------------------------------
Received: (at 266905-done) by bugs.debian.org; 22 Sep 2005 23:18:30 +0000
>From damog@merkel.debian.org Thu Sep 22 16:18:29 2005
Return-path: <damog@merkel.debian.org>
Received: from merkel.debian.org [192.25.206.16] (mail)
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EIaKj-0001oN-00; Thu, 22 Sep 2005 16:18:29 -0700
Received: from damog by merkel.debian.org with local (Exim 3.36 1 (Debian))
id 1EIaKi-0006yS-00; Thu, 22 Sep 2005 17:18:28 -0600
To: 266905-done@bugs.debian.org
Subject: WNPP bug closing
Message-Id: <E1EIaKi-0006yS-00@merkel.debian.org>
From: David Moreno Garza <damog@merkel.debian.org>
Date: Thu, 22 Sep 2005 17:18:28 -0600
Delivered-To: 266905-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,VALID_BTS_CONTROL
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Hello,
This is an automatic mail sent to close the RFP you have reported or
are involved with.
Your RFP wnpp bug is being closed because of the following reasons:
- It is, as of today, older than 365 days.
- It hasn't had any activity recently.
As this an automatic procedure, it could of course have something
wrong and probably it would be closing some bugs that are not
intended by owners and submitters (like you) to be closed, for
example if the RFP is still of your interest, or there has been
some kind of activity around it. In that case, please reopen the
bug, do it, DO IT NOW! (I don't want to be blamed because of
mass closing and not let people know that they can easily reopen
their bugs ;-).
To re-open it, you simply have to mail control@bugs.debian.org
with a body text like this:
reopen 266905
thanks bts
Further comments on the work done in the bug sent to
266905@bugs.debian.org would be truly welcomed.
Anyway, if you have any kind of problems when dealing with
the BTS, feel free to contact me and I'd be more than happy to help
you on this: <damog@debian.org>.
This is the second massive wnpp closing that is being done. The next close
will be done on inactive RFPs older than 365 days and finally, an automatic
script will close, by default, *inactive* RFPs when they reach one year of
inactivity.
A similar process is being applied to other kind of wnpp bugs.
Thanks for your cooperation,
-- David Moreno Garza <damog@debian.org> Thu, 22 Sep 2005 17:06:42 -0500
Reply to: