Re: Still More Secrets of Buffer Cache Enlargement.
On Sun, Jun 09, 2013 at 12:37:26PM -0600, Bob Beck wrote: Greetings all, Here's an up to date version of the buffer flipper that installs on post hackathon -current. This diff (~beck/viagra.diff15) contains one important change from the previous version - In the old cache, as buffers were never freed, we would put B_INVAL buffers in the cache at the head of the clean LRU. (B_INVAL buffers do not contain cachable data - so for example when a remove happens and a file's link count drops to 0, all it's buffers are marked B_INVAL). I noticed after some work with tedu at the end of the hackathon that we kept a lot of data in cache for removed files - it was because of this - and moving to the head of the LRU (behaviour that has been retained since the old static buffer cache) does not make sense with the modern dynamic one - so this diff has changed it to free the B_INVAL buffers right away instead of cacheing them. I'm running this on multiple arches and on my nfs servers feeding them. -Bob No issues so far! At 101% of last port (chromium) on bufferflipper crashing laptop. Ken
Re: Still More Secrets of Buffer Cache Enlargement.
No issues so far! At 101% of last port (chromium) on bufferflipper crashing laptop. Such a nasty name for a laptop that just happened to run a version of my diff with a bug :)
brgphy diff to test on fiber bge(4)
Hi,
Could someone with a fiber bge give the diff below a spin.
The code chunk in question should not be run for fiber PHYs.
There's no change in functionality for non-optical transmitters.
http://svnweb.freebsd.org/base/head/sys/dev/mii/brgphy.c?r1=244480r2=244481
OK's are welcome as well.
diff --git sys/dev/mii/brgphy.c sys/dev/mii/brgphy.c
index fe39a3e..5e18795 100644
--- sys/dev/mii/brgphy.c
+++ sys/dev/mii/brgphy.c
@@ -720,26 +720,25 @@ brgphy_mii_phy_auto(struct mii_softc *sc)
if (sc-mii_flags MIIF_DOPAUSE)
anar |= BRGPHY_SERDES_ANAR_BOTH_PAUSE;
PHY_WRITE(sc, BRGPHY_SERDES_ANAR, anar);
} else {
anar = BMSR_MEDIA_TO_ANAR(sc-mii_capabilities) | ANAR_CSMA;
if (sc-mii_flags MIIF_DOPAUSE)
anar |= BRGPHY_ANAR_ASP | BRGPHY_ANAR_PC;
PHY_WRITE(sc, BRGPHY_MII_ANAR, anar);
+ /* Enable speed in the 1000baseT control register */
+ ktcr = BRGPHY_1000CTL_AFD | BRGPHY_1000CTL_AHD;
+ if (sc-mii_oui == MII_OUI_xxBROADCOM
+ sc-mii_model == MII_MODEL_xxBROADCOM_BCM5701)
+ ktcr |= BRGPHY_1000CTL_MSE | BRGPHY_1000CTL_MSC;
+ PHY_WRITE(sc, BRGPHY_MII_1000CTL, ktcr);
+ ktcr = PHY_READ(sc, BRGPHY_MII_1000CTL);
}
- /* Enable speed in the 1000baseT control register */
- ktcr = BRGPHY_1000CTL_AFD | BRGPHY_1000CTL_AHD;
- if (sc-mii_oui == MII_OUI_xxBROADCOM
- sc-mii_model == MII_MODEL_xxBROADCOM_BCM5701)
- ktcr |= BRGPHY_1000CTL_MSE | BRGPHY_1000CTL_MSC;
- PHY_WRITE(sc, BRGPHY_MII_1000CTL, ktcr);
- ktcr = PHY_READ(sc, BRGPHY_MII_1000CTL);
-
/* Start autonegotiation */
PHY_WRITE(sc, BRGPHY_MII_BMCR,
BRGPHY_BMCR_AUTOEN | BRGPHY_BMCR_STARTNEG);
PHY_WRITE(sc, BRGPHY_MII_IMR, 0xFF00);
return (EJUSTRETURN);
}
Re: DPI for pf(4)
Hi all, adhering to the basic rule of not reinventing the wheel has sort of crippled the efforts to come up with an elegant solution for the topic at hand. Two approaches have been proposed earlier, so let's go through them: (1) Diverting traffic to userspace That's generally a good idea, but defeats the purpose of having zero-latency functionality in pf(4) itself, because going through the scheduler isn't optimal (scheduler people, don't hate me). Worse still, the way TCP incorporates handshakes makes loosely- coupled DPI worthless, because the divert cannot happen before the payload is seen. The only way around this is not diverting at all -- that can only happen with a pf(4) that's completely contained in userspace. I understand the requirement of not doing anything reckless in the kernel and I don't think it's a wise decision to try it anyway. Remember that the goal was to keep consistency and utilise the base functionality in the firewall code itself. (2) bpf(4)-based filters The BPF-VM is neat and the idea of its filters in accordance with the current requirements for the proposed code. However, the amount of work and infrastructure to be built around bpf(4) to avoid any kind of unwanted complexity inside the DPI code is -- at least for me -- not feasible. Instead, the route to take at this point is a userspace library, which can grow, try different things, stumble, explode, adapt, and some day may even be the base of a firewall away from the restriction of the kernel. Others can still implement (1). I don't think (2) will be of much interest in real world applications. Feel free to contact me on and off-list if you have any further questions. :) Thank you all for your participation, Franco
Still looking for 1U servers in western canada.
I'm still looking for 1U servers in western canada. we have an opportunity to build a better build infrastructure for ports but need the gear to do it with. I would be keenly interested in 1) Workable semi-modern amd64 capable intel hardware, 1U - 4 GB of ram or more is nice, One disk drive. (more is nice too). needs a working serial port for serial console, Would be very nice to get 10 or so of these for parallel dpb infrastructure 2) Sparc64 based 1U machines such as sun V210 or V215.. similar to above needs. If they have rails for rack mounting that's even better. They're needed in Edmonton, Alberta - where we have a nice place to host them.
Re: Still looking for 1U servers in western canada.
On Mon, Jun 10, 2013 at 03:21:36PM -0600, Bob Beck wrote: I'm still looking for 1U servers in western canada. we have an opportunity to build a better build infrastructure for ports but need the gear to do it with. I would be keenly interested in 1) Workable semi-modern amd64 capable intel hardware, 1U - 4 GB of ram or more is nice, One disk drive. (more is nice too). needs a working serial port for serial console, Would be very nice to get 10 or so of these for parallel dpb infrastructure Note that, currently, it's better to have MORE smaller machines (2/4 cpu) than big ones. Until we get better SMP support... Our NFS support is probably going to peak around 8 boxen, for now. Having those boxes would really really help VFS people and SMP people get a better idea of the contentions dpb faces...
Re: enable cmp macro for rb-trees in sys/tree.h
On Sun, Jun 9, 2013 at 3:22 PM, Franco Fichtner fra...@lastsummer.de wrote: I've had this patch in my tree for a while. It's just a consistency fix so that cmp can be a plain macro for rb-trees, too. ... - comp = cmp(elm, tmp); \ + comp = (cmp)(elm, tmp); \ Your diff doesn't do what you say it does: adding parens would keep a functional macro from being used. Philip Guenther
Re: enable cmp macro for rb-trees in sys/tree.h
You are right, my mistake. The previous patch was the consistency
patch, but this one actually does what the subject says. The motivation
behind it was the fact that rb trees *almost* support this and I can't
see any harm. The same could be done for splay trees, but I found this
too intrusive without further feedback.
Thanks,
Franco
Index: tree.h
===
RCS file: /OpenBSD/src/sys/sys/tree.h,v
retrieving revision 1.13
diff -u -r1.13 tree.h
--- tree.h 9 Jul 2011 00:19:45 - 1.13
+++ tree.h 11 Jun 2013 05:15:50 -
@@ -594,7 +594,7 @@
tmp = RB_ROOT(head);\
while (tmp) { \
parent = tmp; \
- comp = (cmp)(elm, parent); \
+ comp = cmp(elm, parent);\
if (comp 0) \
tmp = RB_LEFT(tmp, field); \
else if (comp 0) \
