Re: # CONFIG_PREEMPT is not set
> Well, optimize your results you could apply the Low-Latency-Patches and > enable preemption, this should give the best possible result for the > standard kernel with your application. I may give that a go! Many thanks, James ___ Sent Using: Total Carnage WebMail, with NOCC, http://nocc.sourceforge.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
[EMAIL PROTECTED] wrote: Oliver, That does clear things up a bit, even if it is quite a bit to take in... Previous to applying the realtime-lsm patches, audio recording/playback with multi-track hard disk recorders such as Ardour was very laggy and the audio skipped with more than 3 or so tracks. After I installed the new kernel, however, I have benchmarked it to around 20-odd tracks simultaneously playing audio and there was no skipping or patchyness. I assumed before your explanation that the realtime-lsm patch simply enabled faster access to studio-specific audio hardware (such as my Delta 1010 PCI card/outboard). It is apparently though different from the Preempt patches... Well, optimize your results you could apply the Low-Latency-Patches and enable preemption, this should give the best possible result for the standard kernel with your application. (This mail has been unduely delayed because my mouse went bonkers and I had to buy a new one first.) Happy to help, Oliver Korpilla -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Hi Olli, I'm a kernel dummy, so I ask myself what the advantage von PREMPT is, so that I should use it? I personally observe that my Linux is much more responsive when displaying videos with preempt on. Aha, thanx for the answer. I think this could be the reason, why I experience bucking when playing DVD without PREEMT in my kernel... Greetings, Tobias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
El Lunes, 4 de Abril de 2005 19:34, Lionel Elie Mamane escribió: > ... like artsd, the KDE sound daemon? See > http://lists.debian.org/debian-kde/2004/09/msg00199.html . artsd is a bitch for itself, doesn't need any realtime stuff lol -- Rafael Rodríguez - http://djclue.no-ip.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a-- C++ UL++ P++> L++ E--- W+++ N o? K? w--- !O !M V-- PS PE- Y+ PGP+ t--- 5? X R* tv- b- DI- D+ G e++ h! r++ y+ --END GEEK CODE BLOCK--
Re: # CONFIG_PREEMPT is not set
On Tue, Apr 05, 2005 at 01:55:11AM +0200, Oliver Korpilla wrote: > Realtime priorities under Linux are priorities that are higher than > that of any other user process. (...) there is this patch to allow > standard programs to elevate themselves without being run by root. > BTW: This is useful for playing and recording audio, e.g., but > introduces a security risk by allowing normal processes to hog the > CPU and starve the system from resources. But normally that's not a > problem for you, except you have an 0wn3d user account (got "hacked" > by some script kiddies) or have a very stupid application. ... like artsd, the KDE sound daemon? See http://lists.debian.org/debian-kde/2004/09/msg00199.html . -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Oliver, That does clear things up a bit, even if it is quite a bit to take in... Previous to applying the realtime-lsm patches, audio recording/playback with multi-track hard disk recorders such as Ardour was very laggy and the audio skipped with more than 3 or so tracks. After I installed the new kernel, however, I have benchmarked it to around 20-odd tracks simultaneously playing audio and there was no skipping or patchyness. I assumed before your explanation that the realtime-lsm patch simply enabled faster access to studio-specific audio hardware (such as my Delta 1010 PCI card/outboard). It is apparently though different from the Preempt patches... I think the reason I thought they were related is in the kernel configuration (I used menuconfig), under the "Kernel Pre-emption" section was "No pre-emption", a couple of others (cant remember off my head) and "Realtime Latency" :) James Oliver Korpilla <[EMAIL PROTECTED]> wrote : > [EMAIL PROTECTED] > schrieb: > > Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm > on > a 2.6.11 custom-built kernel for using a recording studio with... > > No, there is a mixup of name meanings here. > > Realtime priorities under Linux are priorities that are higher than that > of any other user process. Linux offers 99 levels of those. If a process > is elevated to such a high priority it will not have to compete for the > CPU with other, non-realtime processes, and is therefore mostly safe > from having to long pauses in playing back an audio file or recording one. > > LSM are the Linux Security Modules. This is a framework for fine-grained > security models (beyond the user-or-root model). Because elevating a > process to a RT prio needs root or acquiring a "capability" to > increase > a process' prio (only root usually can do that), there is this patch to > allow standard programs to elevate themselves without being run by root. > > BTW: This is useful for playing and recording audio, e.g., but > introduces a security risk by allowing normal processes to hog the CPU > and starve the system from resources. But normally that's not a problem > for you, except you have an 0wn3d user account (got "hacked" by some > > script kiddies) or have a very stupid application. > > "Real" realtime support like introduced with the preempt patches is > not > simply changing priorities. That stays the same. It enables you to > switch between processes faster if a more important process becomes > runnable. Usually all other processes must wait while one process > executes a system call like read() on a device or open() on a file or > whatever. With preempt the more important process only needs to wait if > the process is in a very critical section of the kernel code where it is > explicitly forbidden to be preempted. The preempt patch therefore lowers > the "average latency" (the time you have to wait for the most > important > process to execute) and allows smoother multimedia. > > Any questions left? Hope I didn't overwhelm you - it's a bit hard to > explain. > > With kind regards, > Oliver Korpilla > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ___ Sent Using: Total Carnage WebMail, with NOCC, http://nocc.sourceforge.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Javier Kohen schrieb: El lun, 04-04-2005 a las 16:02 +0100, [EMAIL PROTECTED] escribiÃ: Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm on a 2.6.11 custom-built kernel for using a recording studio with... No, they're not the same. As far as I can tell, preempt attempts to enhance the user experience (i.e., for programs with a UI) while RT-LSM gives software real-time capabilities. These capabilities give programs deterministic thread scheduling guarantees; not all programs, but those that request this behavior. I do not think so. I think realtime LSM only allows processes to elevate themselves to a realtime priority (a non-dynamic priority, unlike normal processes), so they will run until they give up the CPU. This does not change the realtime behaviour of the kernel in terms of latency, only allows the process to hog the CPU so it cannot get hurt by other less important apps. Since processes are usually only reniced upwards by root, elevating needs a special capability, and therefore it is a patch for a new security model (LSM). With kind regards, Oliver Korpilla -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
[EMAIL PROTECTED] schrieb: Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm on a 2.6.11 custom-built kernel for using a recording studio with... No, there is a mixup of name meanings here. Realtime priorities under Linux are priorities that are higher than that of any other user process. Linux offers 99 levels of those. If a process is elevated to such a high priority it will not have to compete for the CPU with other, non-realtime processes, and is therefore mostly safe from having to long pauses in playing back an audio file or recording one. LSM are the Linux Security Modules. This is a framework for fine-grained security models (beyond the user-or-root model). Because elevating a process to a RT prio needs root or acquiring a "capability" to increase a process' prio (only root usually can do that), there is this patch to allow standard programs to elevate themselves without being run by root. BTW: This is useful for playing and recording audio, e.g., but introduces a security risk by allowing normal processes to hog the CPU and starve the system from resources. But normally that's not a problem for you, except you have an 0wn3d user account (got "hacked" by some script kiddies) or have a very stupid application. "Real" realtime support like introduced with the preempt patches is not simply changing priorities. That stays the same. It enables you to switch between processes faster if a more important process becomes runnable. Usually all other processes must wait while one process executes a system call like read() on a device or open() on a file or whatever. With preempt the more important process only needs to wait if the process is in a very critical section of the kernel code where it is explicitly forbidden to be preempted. The preempt patch therefore lowers the "average latency" (the time you have to wait for the most important process to execute) and allows smoother multimedia. Any questions left? Hope I didn't overwhelm you - it's a bit hard to explain. With kind regards, Oliver Korpilla -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
El lun, 04-04-2005 a las 16:02 +0100, [EMAIL PROTECTED] escribiÃ: > Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm on a > 2.6.11 custom-built kernel for using a recording studio with... No, they're not the same. As far as I can tell, preempt attempts to enhance the user experience (i.e., for programs with a UI) while RT-LSM gives software real-time capabilities. These capabilities give programs deterministic thread scheduling guarantees; not all programs, but those that request this behavior. Cheers, -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: # CONFIG_PREEMPT is not set
Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm on a 2.6.11 custom-built kernel for using a recording studio with... Oliver Korpilla <[EMAIL PROTECTED]> wrote : > Tobias Krais schrieb: > > I'm a kernel dummy, so I ask myself what the advantage von PREMPT is, so > > > that I should use it? > > PREEMPT enables the preemptible kernel, which means you can interrupt > processes executing system calls in kernel mode, except when they are > accessing stuff protected by a spin lock (and is modifying a global data > structure - to avoid data corruption). > > It lowers the average latency when reacting to interrupts. Problem is, > there seem to be some execution paths in the kernel that are pretty > long. The low-latency-kernel teams tries to fix this. > > I personally observe that my Linux is much more responsive when > displaying videos with preempt on. > > With kind regards, > Oliver Korpilla > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ___ Sent Using: Total Carnage WebMail, with NOCC, http://nocc.sourceforge.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Tobias Krais schrieb: I'm a kernel dummy, so I ask myself what the advantage von PREMPT is, so that I should use it? PREEMPT enables the preemptible kernel, which means you can interrupt processes executing system calls in kernel mode, except when they are accessing stuff protected by a spin lock (and is modifying a global data structure - to avoid data corruption). It lowers the average latency when reacting to interrupts. Problem is, there seem to be some execution paths in the kernel that are pretty long. The low-latency-kernel teams tries to fix this. I personally observe that my Linux is much more responsive when displaying videos with preempt on. With kind regards, Oliver Korpilla -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Hi together, PREEMPT for amd64 is currently being worked at in 2.6.12-rc, maybe it will become stable for custom kernels soon. I'm a kernel dummy, so I ask myself what the advantage von PREMPT is, so that I should use it? Greetings, Tobias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Ernest jw ter Kuile wrote: On Thursday 31 March 2005 11:41, Frederik Schueler wrote: PREEMPT for amd64 is currently being worked at in 2.6.12-rc, maybe it will become stable for custom kernels soon. Interesting, and good to know. I've been running with preempt on since day one since buying an AMD64 (using my own kernel) No crashes yet, but I guess from this that i've been lucky. I would have to agree that you've been lucky. I've tested PREEMPT with custom kernels on three Athlon 64 boxes, one MSI K8T and two Abit KV8-PRO's. All experienced problems sooner or later. I think the most any box stayed up without major problems was about one month, by then I usually had to visit locally and reboot. I figure, if anyone is willing to test something with this many reported problems, compiling a custom kernel isn't that much trouble to go through. I rarely use debian packaged kernels, but when I do, it usually has something to do with preferring stability over tuning. With this in mind, I definately agree with the decision to leave this option not set for now. But also keeping in mind the potential gains from PREEMPT, I'd very much appreciate it if people would send further reports if and when the stability on amd64 increases with upcoming kernel versions. /v\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
On Thursday 31 March 2005 11:41, Frederik Schueler wrote: > PREEMPT for amd64 is currently being worked at in 2.6.12-rc, maybe it > will become stable for custom kernels soon. Interesting, and good to know. I've been running with preempt on since day one since buying an AMD64 (using my own kernel) No crashes yet, but I guess from this that i've been lucky. is there a list of kernel drivers known not to work with preemtion on ? Ernest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: # CONFIG_PREEMPT is not set
Hi Frederik, El jue, 31-03-2005 a las 11:41 +0200, Frederik Schueler escribiÃ: > On Thu, Mar 31, 2005 at 09:44:25AM +0200, Marco Amadori wrote: > > Hi all, > > I saw that there is no compiled in support in > > kernel-image-2.6.11-9-amd64-k8 > > for preemptive kernel, although it sit there in the 32 bit kernels. > > i386 kernels up to 2.6.10 are currently the only ones with CONFIG_PREEMT > enabled, starting with 2.6.11 this changed since some drivers Oops or panic > with it enabled (3w- for example). For what concerns amd64, PREEMPT caused > only trouble so far (random Oopses and panics), thus it was deactivated > in the early stages of the kernel-image packages (see the CHangelog, it > happened arounfd August last year). Is it that bad? Damned to know, now it might start causing me trouble after a few months of using PREEMPT on AMD64-64 :) Cheers, -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: # CONFIG_PREEMPT is not set
Alle 11:41, giovedì 31 marzo 2005, Frederik Schueler ha scritto: > > I saw that there is no compiled in support in > > kernel-image-2.6.11-9-amd64-k8 for preemptive kernel, although it sit > > there in the 32 bit kernels. > > i386 kernels up to 2.6.10 are currently the only ones with CONFIG_PREEMT > enabled, starting with 2.6.11 this changed since some drivers Oops or panic > with it enabled (3w- for example). For what concerns amd64, PREEMPT > caused only trouble so far (random Oopses and panics), thus it was > deactivated in the early stages of the kernel-image packages (see the > CHangelog, it happened arounfd August last year). Nice reply, thanks a lot. > > It is a bug or an advice? > > PREEMPT for amd64 is currently being worked at in 2.6.12-rc, maybe it > will become stable for custom kernels soon. So preempt will come back after .12 will be released? -- Marco Amadori :wq
Re: # CONFIG_PREEMPT is not set
Hello, On Thu, Mar 31, 2005 at 09:44:25AM +0200, Marco Amadori wrote: > Hi all, > I saw that there is no compiled in support in kernel-image-2.6.11-9-amd64-k8 > for preemptive kernel, although it sit there in the 32 bit kernels. i386 kernels up to 2.6.10 are currently the only ones with CONFIG_PREEMT enabled, starting with 2.6.11 this changed since some drivers Oops or panic with it enabled (3w- for example). For what concerns amd64, PREEMPT caused only trouble so far (random Oopses and panics), thus it was deactivated in the early stages of the kernel-image packages (see the CHangelog, it happened arounfd August last year). > It is a bug or an advice? PREEMPT for amd64 is currently being worked at in 2.6.12-rc, maybe it will become stable for custom kernels soon. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
