hould be fixed in goodness(), if at all possible,
and not leak out as an undocumented magic number into reschedule_idle().
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software
On Mon, 7 May 2001, Brian Gerst wrote:
> Nigel Gamble wrote:
> >
> > On Mon, 7 May 2001, Linus Torvalds wrote:
> > > On Mon, 7 May 2001, Brian Gerst wrote:
> > > > This patch will still cause the user process to seg fault: The error
> > > > code
s safe to allow preemption after cr2 has been saved */
+ local_irq_restore(regs->eflags);
+
tsk = current;
/*
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software
On Fri, 27 Apr 2001, Mike Galbraith wrote:
> On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > What about SCHED_YIELD and allocating during vm stress times?
>
> snip
>
> > A well-written GUI should not be using SCHED_YIELD. If it is
>
> I was refering to th
it won't be using SCHED_YIELD or be marked
runnable, it will be blocked, waiting until the resource becomes
available. When that happens, it will preempt the compute task (if its
priority is high enough, which is very likely - and can be assured if
it's running at a real-time priority as I
(task->policy == SCHED_FIFO)
+ nice = -99;
+ else
+ nice = task->nice;
read_lock(&tasklist_lock);
ppid = task->p_opptr->pid;
Can anyone think of a better way of doing this?
Nigel Gamble[EMAIL PROTECTED]
Mou
nything else, like serial port timing, etc.?
Why not just run the X server at a realtime priority? Then it will get
to respond to existing events, such as keyboard and mouse input,
promptly without creating lots of superfluous extra clock interrupts.
I think you will find this is a better solution.
On Fri, 20 Apr 2001, Nigel Gamble wrote:
> A SCHED_FIFO or SCHED_RR task with priority n+1 will not preempt a
> running task with priority n. You need to give the higher priority task
> a priority of at least n+2 for it to be chosen by the scheduler.
>
> The problem is caused by
roblem.
Try running xmms as root with the "Use realtime priority when available"
option checked. If the distortion is because xmms isn't getting enough
CPU time, then running it at a realtime priority will fix it.
Nigel Gamble[EMAIL PROTEC
ed = 1;
#endif
}
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
ssible delays in such cases. How's this
> going to work for Linux?
The same way everything works for Linux: with enough people around the
world interested in and working on these problems, they will be fixed.
Nigel Gamble[EMAIL
h as
> > module unloading, where there was a concern that it was not
> > practical to have any sort of lock in the read-side code path and
> > the write side was not time critical.
>
> True, but only if the synchronize_kernel() implementa
re was a concern that it was not practical to have
any sort of lock in the read-side code path and the write side was not
time critical.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software
text switches.
Second, the scheduler should not penalize the preempted task for being
preempted, so that it should usually get to continue running as soon as
the preempting task is descheduled, which is at most one timeslice for
timesharing tasks.
Nigel Gamble[EMA
e because of the problem of avoiding
deadlock on the runqueue lock, which the wait queues also use. The
above code in schedule needs the runqueue lock to protect sync_count.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http:/
ve schedule() point, aren't they, so those tasks are already
safe to access the data we are protecting.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software
On Tue, 20 Mar 2001, Nigel Gamble wrote:
> On Tue, 20 Mar 2001, Rusty Russell wrote:
> > Thoughts?
>
> Perhaps synchronize_kernel() could take the run_queue lock, mark all the
> tasks on it and count them. Any task marked when it calls schedule()
> voluntarily (but not i
r completion */
> down(&sem);
> }
Then consumer could be:
consumer()
{
int i;
start_producers();
/* Wait for 10 items to be produced */
for (i = 0; i < 10; i++)
dow
documentation) it will become widely understood, as
> it offers scalability and efficiency.
Actually, I agree with you now that I've had a chance to think about
this some more.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA.
preemptible kernel, I'm hoping it would be OK to replace
them with a semaphore. Please let me know if this is not the case.
Thanks!
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Sof
others in pgalloc.h. If you know of any other
similar problems on uniprocessors, please let me know.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software [EMAIL PRO
nt CPU for the
duration that the value of smp_processor_id() is used. Or, if the
critical region is very short, to disable interrupts on the local CPU.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
Mont
hat has been preempted is on the run queue and can be
rescheduled on a different CPU, so I can't see how a per-CPU counter
would work. It seems to me that you would need a per run queue
counter, like the example I gave in a previous posting.
Nigel Gamble
f()
only increments current->preempt_count for the preempted task - the
higher priority preempting task that is about to be scheduled will have
a preempt_count of 0.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA.
te current cpu, reschedule */
> while ((current->cpus_allowed &= ~(1 << smp_processor_id())) != 0)
> schedule();
>
> /* Back to normal. */
> current->cpus_allowed = cpus_allowed;
> current->policy = policy;
> current-
ed the generated code)
The other cases are not very common, as they only happen if a task is
preempted during the short time that it is running while in the process
of changing state while going to sleep or waking up, so the default case
is probably OK for them; and I'd
e need to enter the page fault handler with
interrupts disabled to protect the cr2 register. The interrupt state is
restored immediately after cr2 has been saved. Otherwise, an interrupt
could cause the faulting thread to be preempted, and the new thread
could also fault,
the down and up calls are made by different threads. The former
use is a "lock", while the latter down() use is a "potentially blocking
function" in terms of your question. I don't know how easy it would be
for your analysis tools to distinguish between them.
Nigel G
o
move them into sched.h, like d_path(), as I don't want to make it more
difficult to apply kernel patches to my kernel source tree.)
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
diff -Nur 2.4.2/CRED
sequence valid?
> spin_lock_irqsave(a,b);
> spin_lock_irqsave(c,d);
Yes, as long as it is followed by:
spin_unlock_irqrestore(c, d);
spin_unlock_irqrestore(a, b);
Nigel Gamble[EMAIL PROTECTED]
Mountai
latency, we should just use his so-called "RTLinux" environment
for low-latency tasks. RTLinux is not Linux, it is a separate
environment with a separate, limited set of APIs. You can't run XMMS,
or any other existing Linux audio app in RTLinux. I want a low-latency
Linux, not just anothe
rcial axe to grind in
his continual bad-mouthing of IRIX, the internals of which he knows
nothing about.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsu
occurred, since we won't
see the interrupt until it's safe to do the preemptive resched.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsubscrib
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 instea
>
> If so, it's no great surprise that performance dropped given that we replaced
> a spinlock (albeit one guarding somewhat more than the critical section) with
> a semaphore.
>
> Tim
>
> --
> Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROT
n the running process sleeps (voluntarily
or when it has to wait for something) or exits. This is the case in
both of the fully preemptible kernels which I've worked on (IRIX and
REAL/IX).
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA.
bably between 1% and 10% of the
total context switches per second. And it's certainly interesting to me
that I can listen to MP3s without interruption now, while doing a kernel
build!
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA.
On Thu, 4 Jan 2001, Andi Kleen wrote:
> On Thu, Jan 04, 2001 at 01:39:57PM -0800, Nigel Gamble wrote:
> > Experience has shown that adaptive spinlocks are not worth the extra
> > overhead (if you mean the type that spin for a short time
> > and then decide to sleep).
orking on a new implementation that also does priority inheritance,
to avoid the priority inversion problem, and that does the minimum
necessary context switches.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
by definition, disables kernel preemption without the need
to set a no-preempt flag) to protect regions where the lock is held
for a maximum of around 100us, and to use a sleeping mutex lock for
longer regions. This is what I'm working towards.
Nigel Gamble
od enough for most audio apps.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
,
I didn't realise you were still working on this. Did you know that
I am also? Our most recent version is at:
ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/
although I have yet to put up a 2.4.0-prerelease patch (coming soon).
We should probably pool our efforts on this for 2.5.
ot of operating systems already use.
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
aths are now dominated by the big
kernel lock, which we hope can be completely eliminated in 2.5
by finer grained locks.
(I will be at the Linux Real-Time Workshop in Orlando next week, and
may not be able to access my work email address ([EMAIL PROTECTED]),
which is why I'm posting this fr
@@
mntput(p);
return dentry;
}
+ spin_unlock(&dcache_lock);
dput(d);
mntput(p);
+ spin_lock(&dcache_lock);
}
spin_unlock(&dcache_lock);
Nigel Gamble
MontaVista Software
-
To unsu
ment priority
inheritance, until this type of starvation scenario occured!
I'm working on making the linux kernel fully preemptible (as I
did for IRIX when I used to work at SGI), and will need
priority inheritance mutexes to enable real-time behavior for
SCHED_FIFO and SCHED_RR tasks. So someon
You could use a semaphore for this. Initialize it to 0, then call
down() from the ioctl, and up() from the interrupt handler. If the
up() happens before the down(), the down() won't go to sleep.
Nigel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
47 matches
Mail list logo
