[NZLUG] Privacy server

Rob Connolly rob at webworxshop.com
Fri Jun 21 21:41:00 NZST 2013


On Fri, Jun 21, 2013 at 04:34:27PM +1200, Martin D Kealey wrote:
> On Fri, 21 Jun 2013, Rob Connolly wrote:
> > It means the build is able to make use of the hardware floating point
> > support on the chip, rather than emulating those operations in software.
> > This will be faster for programs doing lots of (floating point) maths,
> > but I'm not sure why it should be faster overall, unless the kernel or
> > low level libraries need to do floating point stuff.
> 
> As I understand it, the issue is that if a process does soft floating-point,
> the emulation trap is exceedingly costly (effectively, two extra context
> switches), and depending on how context switches are performed, other
> processes may be penalized.
> 
> Mind you, even HW FP can have some bad effects on process scheduling; with a
> coprocessor FPU, the FP-result-ready interrupt could arrive after the
> initiating process had been switched out, necessitating an extra context
> switch to store the results back into the appropriate process.
> 

I know nothing about the internals of the kernel, but I'm prepared to
wildly speculate that it could/should work better than that.

The FPU coprocessor must communicate with the kernel somehow, usually
this is via an interrupt (IRQ) or direct memory access (DMA). In either
case it shouldn't be necessary for the kernel to wake up the process in
question as it can just buffer the result internally. In fact it can
probably write directly into the memory space of the process without
waking it up and set the process state so that it is no longer waiting
on hardware. When the process is next woken up in it's normal scheduling
slot it should just be able to continue with the result available.

At least that is the way I would design it! There may well be good
reasons why it doesn't work like this. Although I'm pretty experienced
with peripheral drivers in an embedded setting (no OS), I only have
a very rudementary understanding of how schedulers work. I've also never
done any work on the kernel - I keep thinking I should try and get into
it, but lack of time prevails!

Cheers,

Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.nzoss.org.nz/pipermail/nzlug/attachments/20130621/6a7ef8d3/attachment-0001.pgp>


More information about the NZLUG mailing list