How to call a function in the kernel from Local APIC timer handler

Hi, I need some help with the new local APIC functionality added in 
FreeBSD 6.0 and above.

All the code which I am writing is in FreeBSD kernel.

I was using LAPIC one shot timer for scheduling some events in the kernel.
The problem is that I cannot call the function in my code, directly from
the APIC timer handler, because all the interrupts are disabled in the 
APIC timer handler ( function is lapic_handle_timer() ), and my function
uses a sleep mutex to protect the kernel code I have written.
Therefore, I schedule a software interrupt thread, which calls my function 
later in time.
Is there a way, I can call my function instantly from the 
lapic_handle_timer, bcoz using the software interrupt thread, decreases
the accuracy of the scheduler i am using.


thanks
vaibhave


On Fri, 28 Oct 2005, Robert Watson wrote:

> On Thu, 27 Oct 2005, Vaibhave Agarwal wrote:
> 
> > How do u disable malloc debugging flags in the userland? I read somewhere
> > that " ln -s aj /etc/malloc.conf" disables malloc debugging. How does it
> > work?
> > 
> > And how to disable verbose features in the kernel?
> > 
> > Apart from this, are there other ways to make the kernel run faster??
> 
> The note has now been removed, since it was accurate only through the beta
> series.
> 
> "Run faster" is a bit nebulous, as performance optimization is a complex
> thing.  Since you CC'd the net_at_ list, I assume you want the networking to run
> faster.  The usual techniques are:
> 
> - If your workload permits it, run with network stack direct dispatch,
> which avoids a context switch into the network stack.  Be warned that
> this may reduce the opportunities for parallelism between the interrupt
> and link layer code and network layer code, so while it improves many
> workloads, it won't improve all.  Set net.dispatch.direct=1.
> 
> - If your workload benefits from it, consider running with device polling
> -- this moves form an interrupt driven network model to a polled network
> model, greatly decreasing overhead as a result of avoiding thrashing
> interrupt handlers, and allowing you to moderate the load generated by
> the network.  See polling(4) for details, as this requires a custom
> kernel configuration and some careful thought.  This is usually best for
> routers, etc.  Polling may increase the latency of packet processing
> based on how frequently polling polls, but substantially increase
> throughput.
> 
> - Depending on the workload and hardware, you may want to reconsider
> compiling with SMP.  I.e., for some workloads, HTT helps, and SMP helps,
> and for other workloads, it doesn't.
> 
> - Carefully evaluate your hardware configuration -- if this is about
> network performance, you may want to make sure that storage and
> networking devices are on separate PCI buses, and that if needed, those
> buses are 64-bit.
> 
> - Another common hardware issue is shared interrupts -- for example, on
> many motherboards, USB and the on-motherboard network device end up on
> the same interrupt, or their interrupts fire simultaneously regardless
> of the interrupt numbers.  Since the USB code is pretty heavy-weight,
> you don't want to run it every time you receive a batch of packets via
> an interrupt for gig-e.  Compiling out USB in this environment may help.
> This problem can be detected using vmstat -i, and seeing if the
> interrupt rates for USB and your motherboard network device both look
> the same -- i.e., very big.
> 
> - Another common concern with threaded network applications is whether the
> thread library model and implementation match the requirements of your
> application.  FreeBSD provides several thread libraries with different
> properties, so you might want to consider changing thread libraries.
> 
> - Recent reports indicate that on some systems, slow time counters are
> used during context switches.  You may want to consider switching to a
> faster time counter if time accuracy is less important to you.  In one
> measurement, this added 30% performance to loop-back network traffic.
> This issue is being actively researched.
> 
> Other than that, you'll need to tell us what you're doing.
> 
> Robert N M Watson
> 
>