Home

FreeBSD: Testing... Testing...

Submitted by njc
on December 2, 2004 - 1:58pm

Recent development patches committed to FreeBSD's HEAD (-current) and RELENG_5 branches as well as recent patches submitted to the -current, -arch, -threads, -hackers and -net lists need testing in a variety of system configurations. As many know, the quality of future FreeBSD releases is in no small part dependent on user feedback, and FreeBSD developers need feedback on their patches to ensure feature stability and reliability in core subsystems. At present, many of the most important changes in -current surround removing GIANT remnants from various subsystems to make them multi-processor safe, continued integration and improvement of fine-grained locking and ACPI/APIC code. Those users running -current may be interested in stress testing some recent code and reporting findings back to the respective mailing lists.

Jeff Roberson summarizes in his recent VFS patch:

"This patch removes Giant from the read(), write(), and fstat() syscalls,as well as page faults, and bufdone (io interrupts) when using FFS. It adds a considerable amount of locking to FFS and softupdates. You may also use non ffs filesystems concurrently, but they will be protected by Giant. If you are using quotas you should not yet run this patch. I have done some buildworlds, but any heavy filesystem activity would be appreciated."

Read on for a quick round-up of recent patches, the authors original posts and links to their respective threads. This is not a complete list, so please comment if we've missed any!

Recent FreeBSD Patches:

  • Giantless VFS - Removes Giant from read(), write() and fstat() system calls and adds more locking to FFS and softupdates. This code does not currently support filesystem quotas, so it is recommended that you stay away from this patch if you are using them. Testing for this patch under heavy filesystem load (buildworld or comparable) is being sought. Author: Jeff Roberson.

  • nanodelay() patch - A self-calibrating busy loop that operates in nanoseconds which improves small delay intervals compared with DELAY(9). Driver writers are encouraged to test this code. Author: Poul-Henning Kamp.

  • netgraph callout interface - This code removes netgraphs dependence on timeout(9), which is Giant-locked. Users or netgraph coders using ng_bridge, ng_l2tp, ng_lmi, ng_ppp, ng_pppoe or ng_tty are encouraged to test and give feedback. Author: Gleb Smirnoff.

  • MPSAFE sppp w/ Frame Relay Support - Stable mpsafe patches for the sppp(4), cp(4), cx(4), and ctau(4) drivers. Anyone using these devices is encouraged to test and give feedback. Author: Roman Kurakin.

From: Jeff Roberson [email blocked]
To: freebsd-current
Subject: SMP VFS Part 2
Date: 2004-12-01 10:54:49


I have updated the patch at:

http://www.chesapeake.net/~jroberson/smpffs.diff

It includes bug fixes for a handful of problems that were reported, and a
few more that I found myself.  It also unwinds giant from open(), which is
a very high risk area, but after a few days of working out bugs it seems
to be functioning quite well for me.

I did a make -j3 buildworld on a box with a lowered maxvnodes.  I also let
'stress' run for 8 loops or so until I ran into an unrelated KSE bug.  I
did some mount/unmount/single user tests as well.

Use at your own risk.  I still haven't locked quotas, so if you're using
quota, don't run with this patch.

Thanks,
Jeff




From: Poul-Henning Kamp [email blocked]
To: freebsd-arch
Subject: [REVIEW/TEST] nanodelay() vs DELAY()
Date: 2004-11-19 9:37:57

A number of device drivers need to have predictable small delays and
today they largely rely on DELAY() for that.

Problem is, DELAY sucks for durations below 10-20 usec.

I have written a first cut of a self-calibrating nanodelay() which
is better three orders of magnitude further down.

The patch can be found at in p4::phk_dev or

	http://phk.freebsd.dk/patch/nanodelay.patch

nanodelay() takes a nanosecond argument and will try to sleep exactly
that many nanoseconds but never less than that.

With a primed cache, the performance is close to perfect from 200nsec
and up, and below that it depends a lot on the speed of the machine.

Without a primed cache, an unpredictable jitter will be superimposed
on the delay duration.

Here is a plot which shows how DELAY() and nanodelay() perform on two
of my test-machines:

	http://phk.freebsd.dk/misc/nanodelay.png

I would appreciate if driver writers could play with this and
see if makes any difference anywhere.

Please notice that this is a timed cpu-spin, it does not allow
another thread to use the CPU, so it should only be used for
short (< 1/hz) delays.

How it works:

A default routine spins on the timecounter using nanouptime().  How
well this works depends on which timecounter we use, but in general
we can trust it to be OK above a few microseconds.

An array contains function+arg to use for delays less than 8 usec,
for longer delays the timecounter routine is always called.

Each bucket in the array spans 8 nanoseconds, so delays of
0-7 nanoseconds use bucket 0, 8-15 nsec use bucket 1 etc.

A number of cpu based spin routines are calibrated against the
timecounter for various argument values and plugged into the array
accordingly.

The array takes up 9000 bytes on 32 bit and 17000 on 64 bit.  This
can be reduced at the cost of reduced precision in nanodelay(), we
need to determine the correct tradeoff there.

-- 
Poul-Henning Kamp 




From: Gleb Smirnoff [email blocked]
To: freebsd-current
Subject: [TEST] netgraph callout interface
Date: 2004-12-02 15:10:48

Dear collegues,

  we are working on making netgraph ISR mpsafe. To do it we need to
fix all (ab)users of bare timeout(9) in src/sys/netgraph. These
timeout calls are running in synch with netgraph now because timeout(9)
is Giant-locked. As soon as we mark ISR mpsafe, they are going to break.

This patch semi-mechanically changes all timeout(9) calls to ng_callout(9),
which runs scheduled callouts in netgraph context:

	http://people.freebsd.org/~glebius/totest/netgraph_callout

It can be applied to HEAD or RELENG_5 (not 5.3-RELEASE). It patches
the following nodes:

	ng_bridge.c
	ng_l2tp.c
	ng_lmi.c
	ng_ppp.c
	ng_pppoe.c
	ng_tty.c

If you are using at least one of them, then I'm asking you to test the
patch and respond. Thanks in advance!

P.S. Sorry for crossposting. The target users are both RELENG_5 and CURRENT.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE




From: Roman Kurakin [email blocked]
To: freebsd-hackers
Subject: MPSAFE sppp(+fr support) cp cx ctau
Date: 2004-11-28 0:13:10

Hi,

I am glad to announce stable version of patches for sppp, cp, ctau and cx
drivers with support of mpsafe.

SPPP:
Sppp will work in mpsafe mode only for adapters that do not have
IFF_NEEDSGIANT flag.
Also this patch contains if_spppfr.c with fr support for sppp (4).

CP/CX/CTAU:
Adapters will work in mpsafe mode only if both debug.mpsafenet
and debug.{cp|cx|ctau}.mpsafenet set to 1.

Patches (relative current) can be downloaded from:
http://people.freebsd.org/~rik/rik_netperf_20041128-1.pch

Please test them and let me know if you have any problems.

Patches were tested on Tau-PCI - Cisco 2500 at speed 4M
on Dual CPU system with ping-f and uptime ~one week.

rik





Related Links: