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 very
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 havin
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 ri
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 con
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 spin_lock
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 spinloc
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 k
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, 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 sleep
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 littl
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 READ
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
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 dumb
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 though
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 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 "sleepi
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
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 a
25 matches
Mail list logo
