Re: To SMP or not to SMP
On 2013-Jan-07 18:25:58 -0800, Barney Cordoba wrote: >I have a situation where I have to run 9.1 on an old single core >box. Does anyone have a handle on whether it's better to build a non >SMP kernel or to just use a standard SMP build with just the one >core? Another input for this decision is kern/173322. Currently on x86, atomic operations within kernel modules are implemented using calls to code in the kernel, which do or don't use lock prefixes depending on whethur the kernel was built as SMP. My proposed change changes kernel modules to inline atomic operations but always include lock prefixes (effectively reverting r4). I'm appreciate anyone who feels like testing the impact of this change. -- Peter Jeremy pgpA2uS_hItrK.pgp Description: PGP signature
Re: To SMP or not to SMP
On Wednesday, January 09, 2013 06:42:15 PM Konstantin Belousov wrote: > On Wed, Jan 09, 2013 at 03:54:43PM -0500, John Baldwin wrote: > > On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: > > > --- On Wed, 1/9/13, sth...@nethelp.no wrote: > > > > From: sth...@nethelp.no > > > > Subject: Re: To SMP or not to SMP > > > > To: erichsfreebsdl...@alogt.com > > > > Cc: barney_cord...@yahoo.com, freebsd-net@freebsd.org, > > > > jack.vo...@gmail.com, atkin...@gmail.com > > > > > > Date: Wednesday, January 9, 2013, 9:32 AM > > > > > > > > > > 4BSD runs pretty well with > > > > > > > > an SMP kernel. I can test ULE and compare > > > > > > > > > > easily. A no SMP kernel is problematic as the igb > > > > > > > > driver doesn't seem > > > > > > > > > > to work and my onboard NICs are, sadly, igb. > > > > > > > > > > this is bad luck. I know of the kernels as I have had > > > > > > > > SMP and single > > > > > > > > > CPU machines since 4.x times. > > > > > > > > I have had igb working with both SMP and non-SMP kernel for > > > > at least a > > > > year or two, 8.x-STABLE. No specific problems. > > > > > > > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > > > > > > Maybe a problem with "legacy interrupts" on more modern processors? > > > I'm using an E5520 and while the NIC inits ok, it just doesnt seem to > > > gen interrupts. I can't spend much time debugging it > > > > > > I notice that HAMMER kernels use MSI/X interrupts whether SMP is > > > enabled or not, while i386 kernels seem to require APIC. Is there some > > > physical reason for this? > > > > MSI always requires APIC. (MSI interrupts on x86 have to be delivered to > > a local APIC, no way to send them to 8259As.) You can build an i386 > > kernel with device apic but without 'options SMP' which is akin to > > leaving SMP out of an amd64 kernel. > > > > Removing SMP on x86 changes the following things: > > - Spin mutexes just disable interrupts on the local CPU and don't use any > > atomic operations at all. All other lock types work the same. > > - atomic operations don't use the "lock" prefix so are cheaper. However, > > the > > atomic op used for locks (cmpxchg) has an implicit "lock" prefix, so > > this isn't but so much of a gain. > > I do not think that cmpxchg uses implicit lock, and Intel IA32 SDM supports > this view. The absense of the lock prefix makes the instruction decode > faster, and removes the locked bus cycle. > > It is xchg which is implicitely locked, but we no longer use it for unlock. Ah, that's true, for some reason I thought cmpxchg was like xchg in this matter. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Why did KAME need ND6_LLINFO_WAITDELETE?
Hi, I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. I was looking for any historical reasons for why it was needed and what triggered its removal. Any pointers will be much appreciated. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why did KAME need ND6_LLINFO_WAITDELETE?
At Thu, 10 Jan 2013 15:50:30 -0800, prabhakar lakhera wrote: > I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. > I was looking for any historical reasons for why it was needed and what > triggered its removal. I'd normally change history in the original KAME repository: http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.h http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.c (search for "ND6_LLINFO_WAITDELETE") It looks like it was me who made this change but I don't remember details:-) and I don't have time to look into it closer right now. If the rationale is still not clear from the logs and specific code diffs please ask again. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why did KAME need ND6_LLINFO_WAITDELETE?
that is more than helpful :) I myself had a panic because of this state and code in nd6_free because I added an assert to catch connectivity issue.. Found out that it was long gone from stock BSD and kame. Thanks for the pointers!! On Thu, Jan 10, 2013 at 5:48 PM, JINMEI Tatuya / 神明達哉 wrote: > At Thu, 10 Jan 2013 15:50:30 -0800, > prabhakar lakhera wrote: > > > I see that* ND6_LLINFO_WAITDELETE *was done away with long time back. > > I was looking for any historical reasons for why it was needed and what > > triggered its removal. > > I'd normally change history in the original KAME repository: > > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.h > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.c > (search for "ND6_LLINFO_WAITDELETE") > > It looks like it was me who made this change but I don't remember > details:-) and I don't have time to look into it closer right now. > If the rationale is still not clear from the logs and specific code > diffs please ask again. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: kern/174749: Unexpected change of default route
Do some body know how can we debug kernel memory corruption on live system? We need to find out which function/subsystem is cause of this mess. Or maybe is there some way to lock particular memory area, where default gateway lies and watch which subsystem will cause system crash? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route
Old Synopsis: kernel panic on RADIX_MPATH when deleting route New Synopsis: [panic] kernel panic on RADIX_MPATH when deleting route Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 11 07:51:36 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175182 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
