ludovic fernandez wrote:
>
> george anzinger wrote:
>
> > Roger Larsson wrote:
> > >
> >
> > > This part can probably be put in a proper non inline function.
> > > Cache issues...
> > > +/*
> > > +* At that point a scheduling is healthy iff:
> > > +
george anzinger wrote:
> Roger Larsson wrote:
> >
>
> > This part can probably be put in a proper non inline function.
> > Cache issues...
> > +/*
> > +* At that point a scheduling is healthy iff:
> > +* - a scheduling request is pending.
> > +
Roger Larsson wrote:
>
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> > Daniel Phillips wrote:
> > > The key idea here is to disable preemption on spin lock and reenable on
> > > spin unlock. That's a practical idea, highly compatible with the
> > > current way of doing things.
On Fri, 5 Jan 2001, Andi Kleen wrote:
> On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
> > Saying that, I definitely agree that I want/need to one day listen to
> > my MP3s while building my kernel.
>
> ??? I can listen to MP3s just fine while building kernels, on a not
ludovic fernandez wrote:
> Right now I will be interested to run some benchmarks (latency but
> also performance) to see how the system is disturbed by beeing
> preemptable. I'm little bit lost on this and I don't know where to start.
> Do you have any pointers on benchmark suites I could run ?
>
On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
> Saying that, I definitely agree that I want/need to one day listen to
> my MP3s while building my kernel.
??? I can listen to MP3s just fine while building kernels, on a not very
powerful K6.
-Andi
-
To unsubscribe from this
Nigel Gamble wrote:
> On Thu, 4 Jan 2001, ludovic fernandez wrote:
> > This is not the point I was trying to make .
> > So far we are talking about real time behaviour. This is a very
>interesting/exciting
> > thing and we all agree it's a huge task which goes much more behind
> > just
On Thu, 4 Jan 2001, ludovic fernandez wrote:
> This is not the point I was trying to make .
> So far we are talking about real time behaviour. This is a very interesting/exciting
> thing and we all agree it's a huge task which goes much more behind
> just having a preemptive kernel.
You're
Roger Larsson wrote:
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
>
> > I'm not convinced a full preemptive kernel is something
> > interesting mainly due to the context switch cost (actually mmu contex
> > switch).
>
> It will NOT be fully, it will be mostly.
> You will only
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). It is better to use
On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> Daniel Phillips wrote:
> > The key idea here is to disable preemption on spin lock and reenable on
> > spin unlock. That's a practical idea, highly compatible with the
> > current way of doing things. Its a fairly heavy hit on
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). It is better to use spin_lock_irqsave()
> (which, by definition, disables
On Thu, 4 Jan 2001, Andi Kleen wrote:
> The problem is that current Linux semaphores are very costly locks -- they
> always cause a context switch.
My preemptible kernel patch currently just uses Linux semaphores to
implement sleeping kernel mutexes, but we (at MontaVista Software) are
working
On Thu, 4 Jan 2001, Andi Kleen wrote:
> On Thu, Jan 04, 2001 at 08:35:02AM +0100, Daniel Phillips wrote:
> > A more ambitious way to proceed is to change spinlocks so they can sleep
> > (not in interrupts of course). There would not be any extra overhead
>
> Imagine what happens when a non
On Thu, 4 Jan 2001, Daniel Phillips wrote:
> A more ambitious way to proceed is to change spinlocks so they can sleep
> (not in interrupts of course). There would not be any extra overhead
> for this on spin_lock (because the sleep test is handled off the fast
> path) but spin_unlock gets a
Hello Nigel,
Nigel Gamble wrote:
>
> Hi Ludo,
>
> 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/
>
I was on vacation and had a little time to kill...
Going through your
On Wed, 3 Jan 2001, ludovic fernandez wrote:
> For hackers,
> The following patch makes the kernel preemptable.
> It is against 2.4.0-prerelease on for i386 only.
> It should work for UP and SMP even though I
> didn't validate it on SMP.
> Comments are welcome.
Hi Ludo,
I didn't realise you
On Wed, 3 Jan 2001, ludovic fernandez wrote:
> The following patch makes the kernel preemptable.
> It is against 2.4.0-prerelease on for i386 only.
> Comments are welcome.
I think this would be a nice thing to start testing
once 2.5 is forked off.
regards,
Rik
--
Hollywood goes for world
On Thu, Jan 04, 2001 at 11:32:11PM +1100, Anton Blanchard wrote:
>
> > I think a better way to proceed would be to make semaphores a bit more
> > intelligent and turn them into something like adaptive spinlocks and use
> > them more where appropiate (currently using semaphores usually causes
>
> I think a better way to proceed would be to make semaphores a bit more
> intelligent and turn them into something like adaptive spinlocks and use
> them more where appropiate (currently using semaphores usually causes
> lots of context switches where some could probably be avoided). Problem
On Wed, 3 Jan 2001, ludovic fernandez wrote:
+#if 1
+/*
+ * I got some problems with PCMCIA initialization and a
+ * preemptive kernel;
+ * init_pcmcia_ds() beeing called before the completion
+ * of pending scheduled tasks. I don't know if this is the
+ * right fix
Daniel Phillips wrote:
>
> The key idea here is to disable preemption on spin lock and reenable on
> spin unlock. That's a practical idea, highly compatible with the
> current way of doing things. Its a fairly heavy hit on spinlock
> performance, but maybe the overall performance hit is small.
On Wed, 3 Jan 2001, ludovic fernandez wrote:
+#if 1
+/*
+ * I got some problems with PCMCIA initialization and a
+ * preemptive kernel;
+ * init_pcmcia_ds() beeing called before the completion
+ * of pending scheduled tasks. I don't know if this is the
+ * right fix
I think a better way to proceed would be to make semaphores a bit more
intelligent and turn them into something like adaptive spinlocks and use
them more where appropiate (currently using semaphores usually causes
lots of context switches where some could probably be avoided). Problem
is
On Thu, Jan 04, 2001 at 11:32:11PM +1100, Anton Blanchard wrote:
I think a better way to proceed would be to make semaphores a bit more
intelligent and turn them into something like adaptive spinlocks and use
them more where appropiate (currently using semaphores usually causes
lots
On Wed, 3 Jan 2001, ludovic fernandez wrote:
The following patch makes the kernel preemptable.
It is against 2.4.0-prerelease on for i386 only.
Comments are welcome.
I think this would be a nice thing to start testing
once 2.5 is forked off.
regards,
Rik
--
Hollywood goes for world
On Wed, 3 Jan 2001, ludovic fernandez wrote:
For hackers,
The following patch makes the kernel preemptable.
It is against 2.4.0-prerelease on for i386 only.
It should work for UP and SMP even though I
didn't validate it on SMP.
Comments are welcome.
Hi Ludo,
I didn't realise you were
Hello Nigel,
Nigel Gamble wrote:
Hi Ludo,
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/
I was on vacation and had a little time to kill...
Going through your README, you
On Thu, 4 Jan 2001, Daniel Phillips wrote:
A more ambitious way to proceed is to change spinlocks so they can sleep
(not in interrupts of course). There would not be any extra overhead
for this on spin_lock (because the sleep test is handled off the fast
path) but spin_unlock gets a little
On Thu, 4 Jan 2001, Andi Kleen wrote:
The problem is that current Linux semaphores are very costly locks -- they
always cause a context switch.
My preemptible kernel patch currently just uses Linux semaphores to
implement sleeping kernel mutexes, but we (at MontaVista Software) are
working on
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). It is better to use spin_lock_irqsave()
(which, by definition, disables
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). It is better to use
Roger Larsson wrote:
On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
I'm not convinced a full preemptive kernel is something
interesting mainly due to the context switch cost (actually mmu contex
switch).
It will NOT be fully, it will be mostly.
You will only context
Nigel Gamble wrote:
On Thu, 4 Jan 2001, ludovic fernandez wrote:
This is not the point I was trying to make .
So far we are talking about real time behaviour. This is a very
interesting/exciting
thing and we all agree it's a huge task which goes much more behind
just having a
On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
Saying that, I definitely agree that I want/need to one day listen to
my MP3s while building my kernel.
??? I can listen to MP3s just fine while building kernels, on a not very
powerful K6.
-Andi
-
To unsubscribe from this
ludovic fernandez wrote:
Right now I will be interested to run some benchmarks (latency but
also performance) to see how the system is disturbed by beeing
preemptable. I'm little bit lost on this and I don't know where to start.
Do you have any pointers on benchmark suites I could run ?
On Fri, 5 Jan 2001, Andi Kleen wrote:
On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
Saying that, I definitely agree that I want/need to one day listen to
my MP3s while building my kernel.
??? I can listen to MP3s just fine while building kernels, on a not very
Roger Larsson wrote:
On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
Daniel Phillips wrote:
The key idea here is to disable preemption on spin lock and reenable on
spin unlock. That's a practical idea, highly compatible with the
current way of doing things. Its a
george anzinger wrote:
Roger Larsson wrote:
This part can probably be put in a proper non inline function.
Cache issues...
+/*
+* At that point a scheduling is healthy iff:
+* - a scheduling request is pending.
+* -
On Thu, Jan 04, 2001 at 08:35:02AM +0100, Daniel Phillips wrote:
> A more ambitious way to proceed is to change spinlocks so they can sleep
> (not in interrupts of course). There would not be any extra overhead
Imagine what happens when a non sleeping spinlock in a interrupt waits
for a
ludovic fernandez wrote:
> The following patch makes the kernel preemptable.
> It is against 2.4.0-prerelease on for i386 only.
> It should work for UP and SMP even though I
> didn't validate it on SMP.
> Comments are welcome.
I was expecting to see this sometime in 2.5, not quite so soon...
Hello,
For hackers,
The following patch makes the kernel preemptable.
It is against 2.4.0-prerelease on for i386 only.
It should work for UP and SMP even though I
didn't validate it on SMP.
Comments are welcome.
NOTES: since the lock implementation is modified,
you need obviously to re-compile
Hello,
For hackers,
The following patch makes the kernel preemptable.
It is against 2.4.0-prerelease on for i386 only.
It should work for UP and SMP even though I
didn't validate it on SMP.
Comments are welcome.
NOTES: since the lock implementation is modified,
you need obviously to re-compile
ludovic fernandez wrote:
The following patch makes the kernel preemptable.
It is against 2.4.0-prerelease on for i386 only.
It should work for UP and SMP even though I
didn't validate it on SMP.
Comments are welcome.
I was expecting to see this sometime in 2.5, not quite so soon...
The key
On Thu, Jan 04, 2001 at 08:35:02AM +0100, Daniel Phillips wrote:
A more ambitious way to proceed is to change spinlocks so they can sleep
(not in interrupts of course). There would not be any extra overhead
Imagine what happens when a non sleeping spinlock in a interrupt waits
for a
45 matches
Mail list logo
