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

• Previous message: Vladimir Kushnir: "Re: CURRENT + amd64 + user-ppp = panic"
• Next in thread: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Reply: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Reply: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 28 Oct 2005 17:39:13 -0600 (MDT)
To: current@freebsd.org

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@ 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
>
>
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

• Previous message: Vladimir Kushnir: "Re: CURRENT + amd64 + user-ppp = panic"
• Next in thread: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Reply: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Reply: John Baldwin: "Re: How to call a function in the kernel from Local APIC timer handler"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]