Date: Wed, 05 Apr 2006 14:40:31 -0700 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: Luigi Rizzo <rizzo@icir.org>, freebsd-current@freebsd.org Subject: Re: Interesting data on network interrupt - part II Message-ID: <4434394F.8020105@elischer.org> In-Reply-To: <200604051638.59800.jhb@freebsd.org> References: <20060405003358.GA83600@tin.it> <200604051638.59800.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: >On Tuesday 04 April 2006 20:33, Paolo Pisati wrote: > > >>Hi, >> >>i updated my work on interrupt profiling with sone new >>experiments. >> >>In total we have now: >> >>-FreeBSD 4 PIC (no asm part) >>-FreeBSD 7 APIC >>-FreeBSD 7 PIC >>-FreeBSD 7 PREE APIC >>-FreeBSD 7 APIC JHB >> >>Some quick comments: >> >>-PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC) >>-PREE let new thread save less than 500 ticks of 'queue' while >> preempted threads are often resumed after a lot >>-JHB patch shaved 2.5k ticks in interrupt masking op >> >>For graphs, data and more comments: >> >>http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/ >> >> > >I'll commit the patch then. :) One thing you might try to do to better >measure the effects of preemption is to generate kernel work so that >the bge interrupts occur while the current thread is in the kernel >rather than in userland. In that case preemption should provide much >lower latency for interrupt handlers, as w/o preemption, an interrupt >in kernel mode won't run the ithread until either curthread blocks or >returns to userland. > > it looks a bit like the preempted threads shuld be put onto a stack of threads to resume so that when the pre-empter finishes, teh previosly active thread is resumed. Basically, a preempted thread should be put at the HEAD of it's run queue, and not the tail..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4434394F.8020105>