Date: Mon, 26 Jan 2004 15:08:05 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 local_apic.c Message-ID: <20040126150636.E36463-100000@mail.chesapeake.net> In-Reply-To: <200401261026.56106.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jan 2004, John Baldwin wrote: > On Sunday 25 January 2004 12:03 am, Jeff Roberson wrote: > > jeff 2004/01/24 21:03:14 PST > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/i386 local_apic.c > > Log: > > - Don't define DETECT_DEADLOCK. I don't know that this code has > > detected a deadlock in several years. Furthermore, the IPI code is > > currently protected by a seperate spinlock. This only served to make IPIs > > twice as expensive as they had to be which severely slowed down the IPI > > heavy ULE scheduler. > > What spinlock? Er, based on earlier conversations with you I was under the assumption that there was a lock around all of the ipi sender code. I must have this confused with something else. > > > grep mtx local_apic.c | wc -l > 0 > > Some users of the ipi API use a spinlock themselves, but not all, and there > certainly isn't a global ipi spin lock. According to witness, only sparc64 > has an ipi spin lock. It might still be a good idea to turn this off or > perhaps at least half of it. We will lose ipi's on non-XAPIC systems if you > don't wait for the delivery status to clear before sending an IPI. Have you > tested this on Pentium II's or earlier? My original patch did still poll before transmit. I'll correct this. Thanks, Jeff > > -- > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040126150636.E36463-100000>