On Sun, Jan 28, 2001 at 06:14:28AM -0700, [EMAIL PROTECTED] wrote:
> > Yes, I most emphatically do disagree with Victor! IRIX is used for
> > mission-critical audio applications - recording as well playback - and
> And it has bloat, it's famously buggy, it is impossible to maintain, ...
However
Hi!
> > I wasn't thinking of running the kernel XIP from writable, but even
> > trying to do that from the filesystem is a mess. If you're going to be
> > that way about it...
>
> Heh. I am. Read-only XIP is going to be doable, but writable XIP means that
> any time you start to write to the f
Joe deBlaquiere wrote:
~snip~
> The locical answer is run with HZ=1 so you get 100us intervals,
> right ;o).
Lets not assume we need the overhead of HZ=1 to get 100us
alarm/timer resolution. How about a timer that ticks when we need the
next tick...
On systems with multiple hardwa
On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote:
> So then a >100us delay is ok ?
>
> I have a dumb RT perspective: either you have to make the deadline or you don't.
> If you have to make the deadline, then why are you checking need_resched?
In the case I'm describing, it _works_ if you have a >10
> The thing that really does concern me about the flash driver code is the
> fact that it often wants to wait for about 100µs. On machines with
> HZ==100, that sucks if you use udelay() and it sucks if you schedule(). So
> we end up dropping the spinlock (so at least bottom halves can run again)
>
[EMAIL PROTECTED] said:
> no, thats not the logical answer at all. the logical answer is
> something like the excellent but neglected UTIME patch that
> continually reprograms the system timer so that you can get precise
> event scheduling without the insane overhead of HZ=1.
Indeed. Which,
David Woodhouse wrote:
> [EMAIL PROTECTED] said:
>
>> (If you're running a program XIP from flash and a RT interrupt leaves
>> the flash in a unreadable state, boom!).
>
>
> Bad example. I don't expect Linux to support writable XIP any time in the
> near future. The only thing I envisage m
>The locical answer is run with HZ=1 so you get 100us intervals,
>right ;o). On systems with multiple hardware timers you could kick off a
>single event at 200us, couldn't you? I've done that before with the
>extra timer assigned exclusively to a resource. It's not a giant time
>slice, but
[EMAIL PROTECTED] said:
> I wasn't thinking of running the kernel XIP from writable, but even
> trying to do that from the filesystem is a mess. If you're going to be
> that way about it...
Heh. I am. Read-only XIP is going to be doable, but writable XIP means that
any time you start to write
On Sun, Jan 28, 2001 at 06:07:04AM -0800, Bill Huey wrote:
>
> On Sun, Jan 28, 2001 at 06:14:28AM -0700, [EMAIL PROTECTED] wrote:
> > > Yes, I most emphatically do disagree with Victor! IRIX is used for
> > > mission-critical audio applications - recording as well playback - and
> > And it has b
[EMAIL PROTECTED] said:
> A recent example I came across is in the MTD code which invokes the
> erase algorithm for CFI memory. This algorithm spews a command
> sequence to the flash chips followed by a list of sectors to erase.
> Following each sector adress, the chip will wait for 50usec for
Bill Huey wrote:
>
> Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory)
err... It grew. More like 50 now reiserfs is in there. That's counting
real instances - it's not counting ones which are expanded multiple times
as "1".
It could be brought down to 20-25 with goo
[EMAIL PROTECTED] wrote:
>
> ...
>
> I suggest that you get your hearing checked. I'm fully in favor of sensible
> low latency Linux. I believe however that low latency in Linux will
> A. be "soft realtime", close to deadline most of the time.
> B. millisecond level on present h
[EMAIL PROTECTED] said:
> (If you're running a program XIP from flash and a RT interrupt leaves
> the flash in a unreadable state, boom!).
Bad example. I don't expect Linux to support writable XIP any time in the
near future. The only thing I envisage myself doing to help people who want
writ
Andrew Morton wrote:
> There has been surprisingly little discussion here about the
> desirability of a preemptible kernel.
>
And I think that is a very intersting topic... (certainly more
interesting than hotmail's firewalling policy ;o)
Alright, so suppose I dream up an application which I
Roger Larsson wrote:
> On Sunday 28 January 2001 17:17, Joe deBlaquiere wrote:
>
>> Andrew Morton wrote:
>>
>>> There has been surprisingly little discussion here about the
>>> desirability of a preemptible kernel.
>>
>> And I think that is a very intersting topic... (certainly more
>> inter
On Sunday 28 January 2001 17:17, Joe deBlaquiere wrote:
> Andrew Morton wrote:
> > There has been surprisingly little discussion here about the
> > desirability of a preemptible kernel.
>
> And I think that is a very intersting topic... (certainly more
> interesting than hotmail's firewalling poli
[EMAIL PROTECTED] wrote:
> On Mon, Jan 29, 2001 at 11:23:24AM -0600, Joe deBlaquiere wrote:
>
>> while (!done)
>> {
>> done = check_done();
>> }
>>
>> when you can have:
>>
>> while (!done)
>> {
>> yield();
>> done = check_done();
>> }
>
>
> But there is a reason for the fir
On Mon, Jan 29, 2001 at 11:23:24AM -0600, Joe deBlaquiere wrote:
> It doesn't matter how you do it, the cooperative model eventually starts
> to feel like Windoze3.1 in the extreme case, but even so, it was much
> more multithreaded than DOS. Of course, the Right Thing (TM) is to do
> away with
Good morning world! :o)
[EMAIL PROTECTED] wrote:
> Only if your RTLinux application is running. In other words, you cannot
> commit more than 100% of cpu cycle time and expect to deliver.
> I think one of the common difficulties with realtime is that time-shared
> systems with virtual memory mak
On Sun, Jan 28, 2001 at 10:17:46AM -0600, Joe deBlaquiere wrote:
> A recent example I came across is in the MTD code which invokes the
> erase algorithm for CFI memory. This algorithm spews a command sequence
> to the flash chips followed by a list of sectors to erase. Following
> each sector a
Nigel Gamble wrote:
> Yes, I most emphatically do disagree with Victor! IRIX is used for
> mission-critical audio applications - recording as well playback - and
> other low-latency applications. The same OS scales to large numbers of
> CPUs. And it has the best desktop interactive response of
On Sun, 21 Jan 2001, Paul Barton-Davis wrote:
> >Let me just point out that Victor has his own commercial axe to grind in
> >his continual bad-mouthing of IRIX, the internals of which he knows
> >nothing about.
>
> 1) do you actually disagree with victor ?
Yes, I most emphatically do disagree wi
>Let me just point out that Victor has his own commercial axe to grind in
>his continual bad-mouthing of IRIX, the internals of which he knows
>nothing about.
1) do you actually disagree with victor ?
2) victor is not the only person who has expressed this opinion. the
most prolific irix crit
On Sat, 20 Jan 2001 [EMAIL PROTECTED] wrote:
> Let me just point out that Nigel (I think) has previously stated that
> the purpose of this approach is to bring the stunning success of
> IRIX style "RT" to Linux. Since some of us believe that IRIX is a virtual
> handbook of OS errors, it really co
On Fri, Jan 12, 2001 at 07:45:43PM -0700, Jay Ts wrote:
> Andrew Morton wrote:
> >
> > Jay Ts wrote:
> > >
> > > Now about the only thing left is to get it included
> > > in the standard kernel. Do you think Linus Torvalds is more likely
> > > to accept these patches than Ingo's? I sure hope t
Let me just point out that Nigel (I think) has previously stated that
the purpose of this approach is to bring the stunning success of
IRIX style "RT" to Linux. Since some of us believe that IRIX is a virtual
handbook of OS errors, it really comes down to a design style. I think
that simplicity
"David S. Miller" wrote:
>
> Nigel Gamble writes:
> > That's why MontaVista's kernel preemption patch uses sleeping mutex
> > locks instead of spinlocks for the long held locks.
>
> Anyone who uses sleeping mutex locks is asking for trouble. Priority
> inversion is an issue I dearly hope we n
On Sat, Jan 13, 2001 at 12:01:04PM +1100, Andrew Morton wrote:
> Tim Wright wrote:
[...]
> > p_lock(lock);
> > retry:
> > ...
> > if (condition where we need to sleep) {
> > p_sema_v_lock(sema, lock);
> > /* we got woken up */
> > p_lock(lock);
> > goto retry;
> > }
> > ...
>
> Th
[alsa folks, i'd appreciate a comment on this thread from
linux-audio-dev]
hello everyone !
in a post related to his latest low-latency patch, andrew morton
gave a pointer to
http://www.zefiro.com/vgakills.txt , which addresses the problem of
dropped samples due to agressive video drivers hoggin
Andrew Morton wrote:
>
> Jay Ts wrote:
> >
> > Now about the only thing left is to get it included
> > in the standard kernel. Do you think Linus Torvalds is more likely
> > to accept these patches than Ingo's? I sure hope this one works out.
>
> We (or "he") need to decide up-front that Linu
Tim Wright wrote:
>
> Hmmm...
> if is very quick, and is guaranteed not to sleep, then a semaphore
> is the wrong way to protect it. A spinlock is the correct choice. If it's
> always slow, and can sleep, then a semaphore makes more sense, although if
> it's highly contented, you're going to ser
On Sat, 13 Jan 2001, Andrew Morton wrote:
> Nigel Gamble wrote:
> > Spinlocks should not be held for lots of time. This adversely affects
> > SMP scalability as well as latency. That's why MontaVista's kernel
> > preemption patch uses sleeping mutex locks instead of spinlocks for the
> > long he
On Fri, 12 Jan 2001, Tim Wright wrote:
> On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote:
> > what worries me about this is the Apache-flock-serialisation saga.
> >
> > Back in -test8, kumon@fujitsu demonstrated that changing this:
> >
> > lock_kernel()
> > down(sem)
> >
On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote:
> what worries me about this is the Apache-flock-serialisation saga.
>
> Back in -test8, kumon@fujitsu demonstrated that changing this:
>
> lock_kernel()
> down(sem)
>
> up(sem)
> unlock_kernel()
>
> i
Nigel Gamble wrote:
>
> Spinlocks should not be held for lots of time. This adversely affects
> SMP scalability as well as latency. That's why MontaVista's kernel
> preemption patch uses sleeping mutex locks instead of spinlocks for the
> long held locks.
Nigel,
what worries me about this is
"David S. Miller" wrote:
>
> ...
> Bug:In the tcp_minisock.c changes, if you bail out of the loop
> early (ie. max_killed=1) you do not decrement tcp_tw_count
> by killed, which corrupts the state of the TIME_WAIT socket
> reaper. The fix is simple, just duplicate the
Nigel Gamble writes:
> That's why MontaVista's kernel preemption patch uses sleeping mutex
> locks instead of spinlocks for the long held locks.
Anyone who uses sleeping mutex locks is asking for trouble. Priority
inversion is an issue I dearly hope we never have to deal with in the
Linux ker
On Wed, 10 Jan 2001, David S. Miller wrote:
> Opinion: Personally, I think the approach in Andrew's patch
>is the way to go.
>
>Not because it can give the absolute best results.
>But rather, it is because it says "here is where a lot
> of time is spent".
>
>
Just some commentary and a bug report on your patch Andrew:
Opinion: Personally, I think the approach in Andrew's patch
is the way to go.
Not because it can give the absolute best results.
But rather, it is because it says "here is where a lot
of time is spen
> The darn thing disables intrs on its own for quite some time with some of
> the more aggressive drivers. We saw our 20us latencies under RTLinux go up
> a lot with some of those drivers.
It isnt disabling interrupts. Its stalling the PCI bus. Its nasty tricks by
card vendors apparently to get
Jay Ts wrote:
>
> > A patch against kernel 2.4.0 final which provides low-latency
> > scheduling is at
> >
> > http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
> >
> > Some notes:
> >
> > - Worst-case scheduling latency with *very* intense workloads is now
> > 0.8 milliseconds
} > - If you care about latency, be *very* cautious about upgrading to
} > XFree86 4.x. I'll cover this issue in a separate email, copied
} > to the XFree team.
}
} Did that email pass by me unnoticed? What's the prob with XF86 4.0?
The darn thing disables intrs on its own for quite some t
> A patch against kernel 2.4.0 final which provides low-latency
> scheduling is at
>
> http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
>
> Some notes:
>
> - Worst-case scheduling latency with *very* intense workloads is now
> 0.8 milliseconds on a 500MHz uniprocessor.
Wow!
A patch against kernel 2.4.0 final which provides low-latency
scheduling is at
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
Some notes:
- Worst-case scheduling latency with *very* intense workloads is now
0.8 milliseconds on a 500MHz uniprocessor.
For normal worklo
45 matches
Mail list logo
