Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate
On Wed, 26 Mar 2008, Julian Elischer wrote: it wouldn't.. you'd add them together before presenting them. but every time a packet changes a counter that is shared, there is a chance that it is being altered by another processor, so if you have fine grained locking in ipfw, you really should use atomic adds, which are slow, or accept possibl collisions (which might be ok) but still cause a lot of cross cpu TLB flushing. In malloc(9) and uma(9), we maintain per-CPU stats, coalescing only for presentation, relying on soft critical sections rather than locks to pretect consistency. What's worth remembering, however, is that recent multicore machines have significantly optimized the cost of atomic operations on cache lines held for write by the current CPU, and so the cost of locking has dramatically fallen in the last few years. This re-emphasizes the importance of careful cacheline management for per-CPU data structures (particularly, don't put data written by multiple CPUs in the same cacheline if you want the benefits of per-CPU access). Where read-write locking is the best model, Stephan's recent work on rmlocks looks quite promising. In my micro-benchmarks, on recent hardware it performs extremely well on SMP for read locks, but still requires optimization for UP-compiled kernels. For stats and writable structures, such as per-CPU caches, rmlocks aren't very helpful, but when compared with replicating infrequently written data structures across many CPUs, rwlocks/rmlocks offer a much simpler and less error-prone programming model. We need to see more optimization and measurement done on rmlocks for 8.x, and the lack of full priority propagation for rwlocks has to be kept in mind. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: loader and ficl/Forth help
* Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Sun, Feb 24, 2008 at 02:01:14PM -0800, Jeremy Chadwick wrote: > > ... I'll submit a PR for the whole thing. We can hash out > > details/improvements there. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121064 Any news on this? I'm using this patch on my machines at the office. I would love to see it get committed. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpbiLxJ5LKlk.pgp Description: PGP signature
Stupid driver build/debug questions
Hello: New to the FreeBSD kernel and I'm investigating a driver problem (wasn't sure what list this should go on). I was wondering how to make a driver statically built instead of a loadable module? Is this an artifact of the driver source build or the generic kernel configuration mechanism via options etc.? i.e. does a driver need to use something different than the bsd.kmod.mk template make file to build a static driver. What I am trying to do is break at attach time more easily than stepping through driver_probe_and_attach()/driver_attach_child() until the attach routine gets called. I realize I can add a kdb_enter() but I was trying to do this on a live system without rebuilding the kernel (I understand this contradicts my first question but I still want to know how to build drivers statically). Thanks! -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS startup scripts
A little old, but - On Sat, Mar 8, 2008 at 9:53 PM, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > The startup scripts for ZFS are still a little green. One issue is > that the startup script 'requires' mountcritlocal --- I assume because > it figures it requires it so that it's own filesystems will mount on > top of other local UFS ones. No, it requires mountcritlocal because it needs write access to /boot/zfs/zpool.cache and /etc/zfs/exports. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate
Robert Watson wrote: On Tue, 25 Mar 2008, Sepherosa Ziehau wrote: On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer <[EMAIL PROTECTED]> wrote: 3/ possibly keeping per CPU stats.. This probably is the trickest part, not difficult for non-fastforward case. But if fastforward is enabled, I could only imagine full cross-cpu states duplication. FWIW, there is decreasing difference between IP fast forwarding and regular IP processing in FreeBSD 7.x, as we perform direct dispatch by default, so it's not just the fast forward case where full input parallelism is possible for the firewall, and parallel firewall processing has occurred for output since 5.3. The regular forwarding path still does a (partial) copy of each packet it forwards. This is done for the ICMP redirect functionality. Additionally it has a much larger I-cache footprint due to the full ip_input(), ip_forward() and ip_output() functions being executed. Yes, the delta is shrinking but still quite big. I think regular forwarding still hits the wall at around 300-350kpps whereas fastforward can do 500kpps up to 1mpps with a good hardware base. -- Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stupid driver build/debug questions
Alexander Sack wrote:
Hello:
New to the FreeBSD kernel and I'm investigating a driver problem
(wasn't sure what list this should go on).
I was wondering how to make a driver statically built instead of a
loadable module? Is this an artifact of the driver source build or
the generic kernel configuration mechanism via options etc.? i.e.
does a driver need to use something different than the bsd.kmod.mk
template make file to build a static driver.
What I am trying to do is break at attach time more easily than
stepping through driver_probe_and_attach()/driver_attach_child() until
the attach routine gets called. I realize I can add a kdb_enter() but
I was trying to do this on a live system without rebuilding the kernel
(I understand this contradicts my first question but I still want to
know how to build drivers statically).
put the filennames in /sys/conf/files or files.i386 (or whatever)
at one stage you could also have a files.{CONFIGNAME} but I haven't
tried that for a long time.
Thanks!
-aps
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stupid driver build/debug questions
On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Alexander Sack wrote:
> > Hello:
> >
> > New to the FreeBSD kernel and I'm investigating a driver problem
> > (wasn't sure what list this should go on).
> >
> > I was wondering how to make a driver statically built instead of a
> > loadable module? Is this an artifact of the driver source build or
> > the generic kernel configuration mechanism via options etc.? i.e.
> > does a driver need to use something different than the bsd.kmod.mk
> > template make file to build a static driver.
> >
> > What I am trying to do is break at attach time more easily than
> > stepping through driver_probe_and_attach()/driver_attach_child() until
> > the attach routine gets called. I realize I can add a kdb_enter() but
> > I was trying to do this on a live system without rebuilding the kernel
> > (I understand this contradicts my first question but I still want to
> > know how to build drivers statically).
>
> put the filennames in /sys/conf/files or files.i386 (or whatever)
>
> at one stage you could also have a files.{CONFIGNAME} but I haven't
> tried that for a long time.
Thanks for the response. I will try this but I do have an obvious
question, the build scripts do not need to be edited at all with the
extra directory/files? It will just pickup my driver directory and
link against the kernel automagically?
-aps
--
"What lies behind us and what lies in front of us is of little concern
to what lies within us." -Ralph Waldo Emerson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stupid driver build/debug questions
On 27/03/2008, Alexander Sack <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> > Alexander Sack wrote:
> > > Hello:
> > >
> > > New to the FreeBSD kernel and I'm investigating a driver problem
> > > (wasn't sure what list this should go on).
> > >
> > > I was wondering how to make a driver statically built instead of a
> > > loadable module? Is this an artifact of the driver source build or
> > > the generic kernel configuration mechanism via options etc.? i.e.
> > > does a driver need to use something different than the bsd.kmod.mk
> > > template make file to build a static driver.
> > >
> > > What I am trying to do is break at attach time more easily than
> > > stepping through driver_probe_and_attach()/driver_attach_child() until
> > > the attach routine gets called. I realize I can add a kdb_enter() but
> > > I was trying to do this on a live system without rebuilding the kernel
> > > (I understand this contradicts my first question but I still want to
> > > know how to build drivers statically).
> >
> > put the filennames in /sys/conf/files or files.i386 (or whatever)
> >
> > at one stage you could also have a files.{CONFIGNAME} but I haven't
> > tried that for a long time.
>
>
> Thanks for the response. I will try this but I do have an obvious
> question, the build scripts do not need to be edited at all with the
> extra directory/files? It will just pickup my driver directory and
> link against the kernel automagically?
Yes, It will if you add them to standard files list (see conf/files).
(Otherwise if you want it as options directive in your kernel config
than you should mark its module name in conf/files and also put
an appropriate record into conf/options).
-
pluknet
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stupid driver build/debug questions
On Thu, Mar 27, 2008 at 4:39 PM, pluknet <[EMAIL PROTECTED]> wrote:
>
> On 27/03/2008, Alexander Sack <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> > > Alexander Sack wrote:
> > > > Hello:
> > > >
> > > > New to the FreeBSD kernel and I'm investigating a driver problem
> > > > (wasn't sure what list this should go on).
> > > >
> > > > I was wondering how to make a driver statically built instead of a
> > > > loadable module? Is this an artifact of the driver source build or
> > > > the generic kernel configuration mechanism via options etc.? i.e.
> > > > does a driver need to use something different than the bsd.kmod.mk
> > > > template make file to build a static driver.
> > > >
> > > > What I am trying to do is break at attach time more easily than
> > > > stepping through driver_probe_and_attach()/driver_attach_child()
> until
> > > > the attach routine gets called. I realize I can add a kdb_enter()
> but
> > > > I was trying to do this on a live system without rebuilding the
> kernel
> > > > (I understand this contradicts my first question but I still want to
> > > > know how to build drivers statically).
> > >
> > > put the filennames in /sys/conf/files or files.i386 (or whatever)
> > >
> > > at one stage you could also have a files.{CONFIGNAME} but I haven't
> > > tried that for a long time.
> >
> >
> > Thanks for the response. I will try this but I do have an obvious
> > question, the build scripts do not need to be edited at all with the
> > extra directory/files? It will just pickup my driver directory and
> > link against the kernel automagically?
>
> Yes, It will if you add them to standard files list (see conf/files).
> (Otherwise if you want it as options directive in your kernel config
> than you should mark its module name in conf/files and also put
> an appropriate record into conf/options).
Thank you very much, that is what I thought regarding it as an options
directive instead of a driver - I just wanted some validation before
going down that path.
Again, thanks guys,
-aps
--
"What lies behind us and what lies in front of us is of little concern
to what lies within us." -Ralph Waldo Emerson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
