Date: Fri, 28 Oct 2005 17:39:13 -0600 (MDT) From: Vaibhave Agarwal <vaibhave@cs.utah.edu> To: current@freebsd.org Cc: freebsd <freebsd-net@freebsd.org>, Robert Watson <rwatson@FreeBSD.org> Subject: How to call a function in the kernel from Local APIC timer handler Message-ID: <Pine.LNX.4.61.0510281621120.19263@trust.cs.utah.edu> In-Reply-To: <20051028105057.J20147@fledge.watson.org> References: <20051027233636.GA39380@dmw.hopto.org> <Pine.LNX.4.61.0510271744100.19263@trust.cs.utah.edu> <20051028105057.J20147@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.61.0510281621120.19263>