ROSEGARDEN GOES BETA! - 0.9.9 RELEASED
The Rosegarden team are delighted to announce the 0.9.9 release of
Rosegarden 4, an audio and MIDI sequencer and musical notation editor
for Linux.
http://www.rosegardenmusic.com/
This release is feature complete for 1.0 and marks the start of
official b
On Wed, 2004-07-28 at 02:45, Ingo Molnar wrote:
> i'd agree with turning most of the finegrained per-task (non-irq-safe)
> spinlocks into mutexes (or spin-mutexes). But the central locks that an
> RT task would likely hit need to remain spinlocks i believe.
>
> plus there are central mutexes too t
Hi!
> > Well, I do not follow you I guess.
> >
> > With large-enough number of hardirqs you do no progress at all.
> >
> > Even if only "sane" number of irqs, if they all decide to hit within one
> > getpid(), this getpid is going to take quite long
> > Pavel
>
>
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> ...
> > [the only remaining source of 'latency uncertainty' is the small
> > asynchronous hardirq stub that would still remain. This has an effect
> > that can be compared to e.g. cache effects and it cannot become unbound
> > unless the CPU is bombarde
On Thu, Jul 29, 2004 at 10:26:30PM +0200, Pavel Machek wrote:
> Well, I do not follow you I guess.
>
> With large-enough number of hardirqs you do no progress at all.
>
> Even if only "sane" number of irqs, if they all decide to hit within one
> getpid(), this getpid is going to take quite long..
Hi!
> i did not say latency sources, i said unpredictable latency sources.
> hardirq and softirq processing introduces near arbitrary latency at any
> (irqs-enabled) point in the kernel. Hence they make all kernel code
> unbound in essence - even the most trivial kernel code, sys_getpid().
...
>
On Thu, Jul 29, 2004 at 03:17:52PM -0400, Scott Wood wrote:
> On Thu, Jul 29, 2004 at 11:36:26AM -0700, Bill Huey wrote:
> There are legitimate reasons to use smp_processor_id() outside of a
> non-preemptible region, though. These include debugging
> printks/logging, and situations where the aware
On Thu, Jul 29, 2004 at 11:36:26AM -0700, Bill Huey wrote:
> On Thu, Jul 29, 2004 at 08:21:10PM +0200, Ingo Molnar wrote:
> > * Scott Wood <[EMAIL PROTECTED]> wrote:
> > ok, i see - this makes 100% sense. I'm wondering how intrusive such an
> > all-preemptive patchset is? There are some problems wi
On Thu, Jul 29, 2004 at 08:21:10PM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
> ok, i see - this makes 100% sense. I'm wondering how intrusive such an
> all-preemptive patchset is? There are some problems with per-CPU data
> structures on SMP. Right now holding a spinlock m
* Scott Wood <[EMAIL PROTECTED]> wrote:
> Those critical sections where lock-breaking has been done can be
> converted back into spinlocks. Essentially, mutexes would be used for
> "untrusted" locks, as opposed to using spinlocks just where they're
> absolutely necessary. Over time, the set of
* Bill Huey <[EMAIL PROTECTED]> wrote:
> There are also other problem with moving to a largely sleeping mutex
> style kernel, dead lock detection becomes sorely needed. Current
> spinlock detection methods are probably going to be useless in a
> system like this. [...]
i have another worry with
On Wed, Jul 28, 2004 at 08:45:47AM +0200, Ingo Molnar wrote:
> i have another worry with the 'everything is a mutex' concept. Currently
> we still do have a number of 'central' locks such as dcache_lock, or the
> SLAB locks. So even if all (but the scheduling) spinlocks are converted
> to sleeping
==
FSMSI 2004
European seminar
on
"Free Software for Multimedia Streaming over the Internet"
June 23/24,
Note that the method used by hdparm tends to underreport
achievable throughput somewhat, because it generally only
ever has one I/O "in flight".
Cheers
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
Lee Revell wrote:
On Tue, 2004-07-20 at 08:19, Jens Axboe wrote:
On Tue, Jul 20 2004, I
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
You wouldn't need to do this to break out of interrupt context
softirqs because you wouldn't bother returning to it. Just hand the
work off to ksoftirqd.
this is plainly not the case. Look at eg. the net_tx_action() lock-break
i did in t
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> You wouldn't need to do this to break out of interrupt context
> softirqs because you wouldn't bother returning to it. Just hand the
> work off to ksoftirqd.
this is plainly not the case. Look at eg. the net_tx_action() lock-break
i did in the -I1 patch
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
look at my latest patches to see how it's done. We can preempt softirq
handlers via lock-break methods. The same method doesnt work in the idle
Are you referring to this patch?
http://people.redhat.com/mingo/voluntary-preempt/defer-softir
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >look at my latest patches to see how it's done. We can preempt softirq
> >handlers via lock-break methods. The same method doesnt work in the idle
>
> Are you referring to this patch?
> http://people.redhat.com/mingo/voluntary-preempt/defer-softirqs-2.
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
this doesnt work either: once we've committed ourselves to do an
'immediate' softirq processing pass we are risking latencies. We cannot
preempt the idle task while it's processing softirqs the same way we can
do the lock-break if they ar
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >this doesnt work either: once we've committed ourselves to do an
> >'immediate' softirq processing pass we are risking latencies. We cannot
> >preempt the idle task while it's processing softirqs the same way we can
> >do the lock-break if they are alwa
--On Wednesday, 21 July 2004 12:53 p.m. +0200 Florian Schmidt
<[EMAIL PROTECTED]> wrote:
Hi,
interesting that you mention the Xserver. I use a dual graphics card
setup atm [Nvidia GF3 TI and some matrox pci card]. The nvidia card seems
to work flawlessly even with HW accelleration [i use nvidias
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
this is insufficient too. An RT task might be _waiting to run_ and
spending our time in a non-RT context (including the idle task) doing
softirq processing might delay it indefinitely.
what we could do is to add a rq->nr_running_rt and do
On Thu, Jul 22, 2004 at 02:53:08PM -0400, Scott Wood wrote:
> On Thu, Jul 22, 2004 at 09:40:34AM +0200, Ingo Molnar wrote:
> > * Scott Wood <[EMAIL PROTECTED]> wrote:
> > > This sort of substitution is what we did in 2.4, though we made this
> > > type the default and gave the real spinlocks a new
On Thu, 2004-07-22 at 14:36 -0400, Scott Wood wrote:
> This is assuming that a high-priority non-RT task will always preempt
> a lower priority task except when it has depleted its timeslice; I'm
> not familiar enough with the current scheduler to know whether that
> is the case.
Yes, this is the
On Thu, Jul 22, 2004 at 09:40:34AM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
> > This sort of substitution is what we did in 2.4, though we made this
> > type the default and gave the real spinlocks a new name to be used in
> > those few places where it was really needed.
On Thu, Jul 22, 2004 at 11:51:11AM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
> > I meant the current split between immediate-context softirqs (which
> > are repesented in the patch by the high-priority ksoftirqd) and the
> > low-priority thread which is used to avoid starv
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
Given that we're looking for something acceptable for 2.6, how about
adding
if (rt_task(current))
kick ksoftirqd instead
Otherwise, what is the performance penalty of doing all softirq
processing from ksoftirqd?
this is insuffici
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >this is insufficient too. An RT task might be _waiting to run_ and
> >spending our time in a non-RT context (including the idle task) doing
> >softirq processing might delay it indefinitely.
> >
> >what we could do is to add a rq->nr_running_rt and do t
* Scott Wood <[EMAIL PROTECTED]> wrote:
> > trying to make softirqs preemptible surely wont fly for 2.6 and it will
> > also overly complicate the softirq model. What's so terminally wrong
> > about adding preemption checks to the softirq paths? It should solve the
> > preemption problem for good
* Scott Wood <[EMAIL PROTECTED]> wrote:
> > what high/low semantics do you mean, other than the ordering of softirq
> > sources? (which is currently implemented via the __do_softirq() loop
> > first looking at the highest prio softirq.) So splitting up ksoftirqd
> > into two pieces seems like a s
* Scott Wood <[EMAIL PROTECTED]> wrote:
> > if both hardirqs and softirqs are redirectable to process contexts then
> > the only unpredictable latency would be the very short IRQ entry stub of
> > a new hardirq costing ~5 usecs - which latency is limited in effect
> > unless the CPU is hopelessly
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Given that we're looking for something acceptable for 2.6, how about
> adding
>
> if (rt_task(current))
> kick ksoftirqd instead
>
> Otherwise, what is the performance penalty of doing all softirq
> processing from ksoftirqd?
this is insufficient
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
What do you think about deferring softirqs just while in critical
sections?
I'm not sure how well this works, and it is CONFIG_PREEMPT only but in
theory it should prevent unbounded softirqs while under locks without
taking the performanc
On Wed, Jul 21, 2004 at 11:08:32PM +0200, Ingo Molnar wrote:
> did you get my other mail in which i explained how e.g. the networking
> code _relies_ on the softirq semantics?
Yes, but not until after I sent that e-mail.
> > Do you also add preemption checks in all of the various loops that can
>
On Wed, Jul 21, 2004 at 08:43:08PM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
> > What aspects of it do you find unnecessary? The second thread is
> > needed to maintain the current high/low priority semantics (without
> > that, you'll either starve regular tasks with a lo
On Wed, Jul 21, 2004 at 11:45:34PM +0200, Ingo Molnar wrote:
> do you have a 2.6 patch for hardirq redirection too?
Yes, and I'll try to get it cleaned up and posted soon. It depends
on threaded softirqs, though (so I'll have to do something with the
local_bh_disable; probably put it back to the
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> What do you think about deferring softirqs just while in critical
> sections?
>
> I'm not sure how well this works, and it is CONFIG_PREEMPT only but in
> theory it should prevent unbounded softirqs while under locks without
> taking the performance hit
* Scott Wood <[EMAIL PROTECTED]> wrote:
> > > You're still running do_softirq() with preemption disabled, which is
> > > almost as bad as doing it under a lock.
> >
> > well softirqs are designed like that.
>
> And those who wish to continue using them like that can. However, in
> my patch th
* Scott Wood <[EMAIL PROTECTED]> wrote:
> Likewise, interrupts are "designed" to be unpreemptible, but it is
> possible to run them in their own threads so as to further reduce
> sources of latency (at a throughput cost, of course). This allows
> long-held spinlocks that an interrupt handler nee
Scott Wood wrote:
On Wed, Jul 21, 2004 at 09:32:46PM +1000, Nick Piggin wrote:
What do you think about deferring softirqs just while in critical
sections?
I'm not sure how well this works, and it is CONFIG_PREEMPT only
but in theory it should prevent unbounded softirqs while under
locks without tak
On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
>
> > It appears, though, that recent kernel versions do preempt_disable()
> > in ksoftirqd, apparently to support CPU hotplugging[1]. When I
> > originally made the patch (against 2.6.0), this
* Scott Wood <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 21, 2004 at 10:52:46AM +0200, Ingo Molnar wrote:
> > this, if enabled, causes all softirqs to be processed within ksoftirqd,
> > and it also breaks out of the softirq loop if preemption of ksoftirqd
> > has been triggered by a higher-prio task
* Scott Wood <[EMAIL PROTECTED]> wrote:
> > we already 'daemonize' softirqs in the stock kernel if the load is high
> > enough. (this is what ksoftirqd does) So the only question is a tunable
> > to make this deferring of softirq load mandatory. Yarroll's patch is
> > quite complex, i dont think
* Scott Wood <[EMAIL PROTECTED]> wrote:
> It appears, though, that recent kernel versions do preempt_disable()
> in ksoftirqd, apparently to support CPU hotplugging[1]. When I
> originally made the patch (against 2.6.0), this wasn't the case.
> Since it was done so recently, hopefully there are
On Wed, Jul 21, 2004 at 02:30:10PM -0400, Scott Wood wrote:
> Why is it "clearly wrong"? As far as I can tell, the only legitimate
> use of it currently is to protect against deadlock (as in
> spin_lock_bh()), which is not an issue if all softirqs run from a
> thread. Ksoftirqd already ignores su
On Wed, Jul 21, 2004 at 08:46:50PM +0200, Ingo Molnar wrote:
> * Scott Wood <[EMAIL PROTECTED]> wrote:
>
> > You're still running do_softirq() with preemption disabled, which is
> > almost as bad as doing it under a lock.
>
> well softirqs are designed like that.
And those who wish to continue
On Wed, Jul 21, 2004 at 09:32:46PM +1000, Nick Piggin wrote:
> What do you think about deferring softirqs just while in critical
> sections?
>
> I'm not sure how well this works, and it is CONFIG_PREEMPT only
> but in theory it should prevent unbounded softirqs while under
> locks without taking t
* Scott Wood <[EMAIL PROTECTED]> wrote:
> You're still running do_softirq() with preemption disabled, which is
> almost as bad as doing it under a lock.
well softirqs are designed like that. I've added extra preemption code
to the latest patch to avoid repeat processing.
Ingo
Ingo Molnar wrote:
below i've also attached a softirq.c patch against 2.6.8-rc2 that does
unconditional deferring. (this patch is of course not intended to be
merged upstream as-is, since normally we want to process softirqs
right after the irq context.)
i've got a more complete patch against vani
On Wed, Jul 21, 2004 at 10:52:46AM +0200, Ingo Molnar wrote:
> this, if enabled, causes all softirqs to be processed within ksoftirqd,
> and it also breaks out of the softirq loop if preemption of ksoftirqd
> has been triggered by a higher-prio task.
You'll still have the latency of finishing the
On Wed, Jul 21, 2004 at 10:22:18AM +0200, Ingo Molnar wrote:
> we already 'daemonize' softirqs in the stock kernel if the load is high
> enough. (this is what ksoftirqd does) So the only question is a tunable
> to make this deferring of softirq load mandatory. Yarroll's patch is
> quite complex, i
Lee Revell wrote:
There are still a few areas that need work, ioctl gives me problems, but
the latest 2.6 kernels are quite good. If you look at the 'clean'
version of the voluntary kernel preemption patch it is pretty small. My
understanding is that the kernel is already preemptible anytime tha
On Tue, Jul 20 2004, Ingo Molnar wrote:
> > How much I/O do you allow to be in flight at once? It seems like by
> > decreasing the maximum size of I/O that you handle in one interrupt
> > you could improve this quite a bit. Disk throughput is good enough,
> > anyone in the real world who would fe
* Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> As Ingo basically showed (and I agree), all current might_sleep seems
> suitable to be converted to cond_resched. I checked all them and
> there's none that seems to be called in a loop for no good reason. the
> ones in the semaphore are quite nice
On Wed, Jul 21, 2004 at 03:14:23PM -0700, Bill Huey wrote:
> On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
> > trying to make softirqs preemptible surely wont fly for 2.6 and it will
> > also overly complicate the softirq model. What's so terminally wrong
> > about adding preemption
On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
> trying to make softirqs preemptible surely wont fly for 2.6 and it will
> also overly complicate the softirq model. What's so terminally wrong
> about adding preemption checks to the softirq paths? It should solve the
> preemption probl
Hi all,
Due to some family problems and lot of pressure at work I have not been
able to spend as much time as needed on my audio projects in the last few
months. This means that many of them have patch backlogs and TODOs with 6
month old jobs on then and I'm starting to loose track of things. The
57 matches
Mail list logo
