On Thu, 16 Jul 2009, Peter Zijlstra wrote:
quoted text
> On Wed, 2009-07-15 at 19:11 -0400, Ted Baker wrote:
> > Again, I don't think that either PP or PI is appropriate for use
> > in a (SMP) kernel. For non-blocking locks, the current
> > no-preeemption spinlock mechanism works.  For higher-level
> > (blocking) locks, I'm attracted to Jim Anderson's model of
> > non-preemptable critical sections, combined with FIFO queue
> > service.
> 
> Right, so there's two points here I think:
> 
>  A) making most locks preemptible
>  B) adding PI to all preemptible locks
> 
> I think that we can all agree that if you do A, B makes heaps of sense,
> right?
> 
> I just asked Thomas if he could remember any numbers on this, and he
> said that keeping all the locks non-preemptible had at least an order
> difference in max latencies [ so a 60us (A+B) would turn into 600us (!
> A) ], this means a proportional decrease for the max freq of periodic
> tasks.

That are numbers from about 3 years ago. I need to redo the tests as
we did lot of lock breaks and shortening of preempt/irq disabled
sections since then, but when we started preempt-rt there was no real
choice as the limited number of developers simply did not allow to
analyse and fix all the long lasting critical sections. We were busy
enough to fix all the locking problems which were unearthed. :) Also
we did not have the tools to analyse the length of critical sections
back then. 

It's definitely worthwhile to revisit this, but that's going to be a
multi man years effort to distangle complex code pathes like the
network stack, disk i/o and other known sources of trouble. The next
challenge will be how to monitor the code base for regressions and
keeping thousands of developers aware of these requirements.

quoted text
> This led to the conviction that the PI overheads are worth it, since
> people actually want high freq tasks.
>
> Of course, when the decreased period is still sufficient for the
> application at hand, the non-preemptible case allows for better
> analysis.

Agreed, but the real challenge of providing real time services in
Linux is the wide variety of use cases. We simply need to accept that
people want to use it from

  high frequency industrial control tasks while running a GUI, a
  webserver and a database on the same machine

to

  heavily threaded enterprise class Java applications which do not
  care that much about latencies but need the correctness guarantees

and of course everything in between.

I'm well aware that we try to create something which does everything
except of playing the National Anthem, but simply restricting the use
cases is not an option and would be exceptionally boring as well :)

Thanks,

	tglx
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/