Re: PATCH: Virtio memory balooning
Hi,
Here is a updated version:
- fixes panic when host requests more memory to deflate than guest has
- some cleanup
Index: files.pci
===
RCS file: /cvs/src/sys/dev/pci/files.pci,v
retrieving revision 1.289
diff -u -r1.289 files.pci
--- files.pci 29 Oct 2012 18:36:42 - 1.289
+++ files.pci 6 Nov 2012 10:34:22 -
@@ -837,3 +837,7 @@
device vioblk: scsi
attach vioblk at virtio
file dev/pci/vioblk.cvioblk
+
+device viomb
+attach viomb at virtio
+file dev/pci/viomb.c viomb
Index: GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.741
diff -u -r1.741 GENERIC
--- GENERIC 8 Oct 2012 17:26:02 - 1.741
+++ GENERIC 6 Nov 2012 10:36:25 -
@@ -799,3 +799,4 @@
virtio*at pci? # Virtio PCI device
vioblk*at virtio? # Virtio block device
vio* at virtio? # Virtio network device
+viomb* at virtio? # Virtio memory ballooning device
--- /dev/null Thu Nov 8 11:03:03 2012
+++ sys/dev/pci/viomb.c Thu Nov 8 11:02:31 2012
@@ -0,0 +1,447 @@
+/* $OpenBSD$*/
+/* $NetBSD: viomb.c,v 1.1 2011/10/30 12:12:21 hannken Exp $ */
+/*
+ * Copyright (c) 2012 Dinar Talypov
+ * Copyright (c) 2010 Minoura Makoto.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#defineDEVNAME(sc) sc->sc_dev.dv_xname
+
+#if VIRTIO_DEBUG
+#define VIOMBDEBUG(sc, format, args...)\
+ do { printf("%s: " format, sc->sc_dev.dv_xname, ##args);} \
+ while (0)
+#else
+#define VIOMBDEBUG(...)
+#endif
+
+/* flags used to specify kind of operation,
+ * actually should be moved to virtiovar.h
+ */
+#define VRING_READ 0
+#define VRING_WRITE1
+
+/* notify or don't notify */
+#define VRING_NO_NOTIFY0
+#define VRING_NOTIFY 1
+
+/* Configuration registers */
+#define VIRTIO_BALLOON_CONFIG_NUM_PAGES0 /* 32bit */
+#define VIRTIO_BALLOON_CONFIG_ACTUAL 4 /* 32bit */
+
+/* Feature bits */
+#define VIRTIO_BALLOON_F_MUST_TELL_HOST (1<<0)
+#define VIRTIO_BALLOON_F_STATS_VQ (1<<1)
+
+static const struct virtio_feature_name viomb_feature_names[] = {
+ {VIRTIO_BALLOON_F_MUST_TELL_HOST, "TellHost"},
+ {VIRTIO_BALLOON_F_STATS_VQ, "StatVQ"},
+ {0, NULL}
+};
+#define PGS_PER_REQ256 /* 1MB, 4KB/page */
+#define VQ_INFLATE 0
+#define VQ_DEFLATE 1
+
+struct balloon_req {
+ bus_dmamap_tbl_dmamap;
+ struct pglist bl_pglist;
+ int bl_nentries;
+ uint32_tbl_pages[PGS_PER_REQ];
+};
+
+struct viomb_softc {
+ struct device sc_dev;
+ struct virtio_softc *sc_virtio;
+
+ struct virtqueuesc_vq[2];
+ u_int32_t sc_npages;
+ u_int32_t sc_actual;
+ u_int32_t sc_balloon_size;
+ int sc_inflight;
+ struct balloon_req sc_req;
+ struct pglist sc_balloon_pages;
+ int sc_flags;
+#define INFALTE_DONE 0x01
+#define DEFLATE_DONE 0x02
+};
+
+int viomb_match(struct device *, void *, void *);
+voidviomb_attach(struct device *, struct device *, void *);
+int viomb_intr(void *);
+voidviomb_inflate(void *, void *);
+voidviomb_deflate(void *, void *);
+int viomb_config_change(struct virtio_softc *);
+
Re: upstream vendors and why they can be really harmful
On Wed, 7 Nov 2012 22:52:19 +0100 Lars von den Driesch wrote: > > The only distros with a fair few users who have switched and still > > have far less users are Fedora, Mageia and OpenSUSE. > > Let's have an eye on Arch-Linux. And they have lost users over it. I left them out because they have few users in comparison. What do you mean by having an eye? To me, Arch has absolutely zero bearing on what I have said?
Re: upstream vendors and why they can be really harmful
On Wed, Nov 7, 2012 at 6:39 PM, Kevin Chadwick wrote: > The only distros with a fair few users who have switched and still > have far less users are Fedora, Mageia and OpenSUSE. Let's have an eye on Arch-Linux. They have switched to systemd recently and seem to be very confident about it. For me that is a reason to have a look on alternatives. But in linux-land it is becoming difficult. For my personal taste there are only Crux, Slackware and Gentoo left. Lars
Re: upstream vendors and why they can be really harmful
Tomas Bodzar [tomas.bod...@gmail.com] wrote: > > Here you can read what Linux devs think about Dfly for example > https://plus.google.com/101384639386588513837/posts/Dkb8iixE4eP Yes, let's all work on Linux!!! Let's all move to Texas. And, what's with this water? Like in the toilets? What about Brawndo?
Re: upstream vendors and why they can be really harmful
On Wed, Nov 7, 2012 at 9:40 PM, William Ahern wrote: > On Tue, Nov 06, 2012 at 06:24:58PM -0200, Daniel Bolgheroni wrote: >> On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: >> > >> > It's also quickly turning Posix and Unix into a travesty: either you have >> > the linux goodies, or you don't. And if you don't, you can forget anything >> > modern... >> >> This IS the main problem. > > The BSDs definitely need to find a way to join the inner circle at the Open > Group. Or maybe there are already BSD developers there. It's hard to know as > an outsider because the process is so opaque. > Here you can read what Linux devs think about Dfly for example https://plus.google.com/101384639386588513837/posts/Dkb8iixE4eP
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 06:24:58PM -0200, Daniel Bolgheroni wrote: > On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: > > > > It's also quickly turning Posix and Unix into a travesty: either you have > > the linux goodies, or you don't. And if you don't, you can forget anything > > modern... > > This IS the main problem. The BSDs definitely need to find a way to join the inner circle at the Open Group. Or maybe there are already BSD developers there. It's hard to know as an outsider because the process is so opaque.
Re: em(4): enable TCP/UDP checksum offload
and these also look good: > dmesg|grep ^em em0 at pci3 dev 0 function 0 "Intel PRO/1000 PT (82572EI)" rev 0x06: apic 2 int 17, address X:X:X:X:X:X > ifconfig em hwfeatures em0: flags=8843 mtu 1500 hwfeatures=36 lladdr X:X:X:X:X:X priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active # dmesg|grep ^em em0 at pci0 dev 25 function 0 "Intel ICH8 IGP M AMT" rev 0x03: msi, address X:X:X:X:X:X # ifconfig em0 hwfeatures em0: flags=8843 mtu 1500 hwfeatures=36 lladdr X:X:X:X:X:X priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active I will keep the patch enabled on these interfaces and report if there should be any problems which I didn't notice yet. Best Regards Andreas
Re: [cwm 1/1] Add a menu to search and call internal functions.
> > Why not
> >
> > for (iter = 0; iter < nitems(name_to_kbfunc); iter++) {
> > func = &name_to_kbfunc[iter]; /* if you want to use func */
> >
> > then you don't need the last NULL entry in the array or add code
> > to not break existing code.
>
> See: http://c-faq.com/decl/extarraysize.html
>
> The diff moves the declaration of name_to_kbfunc[] to calmwm.h and
> externs it for use in kbfunc.c, but it's still defined in conf.c.
>
Yeah, I see that now, though the use of nitems is used throughout
the code already and deviating from that and making that particular
array a "special case" seems kind of messy and somewhat confusing.
Re: em(4): enable TCP/UDP checksum offload
looks good: # dmesg |grep ^em em0 at pci9 dev 0 function 0 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 0 int 8, address X:X:X:X:X:X em1 at pci9 dev 0 function 1 "Intel PRO/1000 PT (82571EB)" rev 0x06: apic 0 int 18, address X:X:X:X:X:X # ifconfig em hwfeatures em0: flags=8b43 mtu 1500 hwfeatures=36 lladdr X:X:X:X:X:X priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8b43 mtu 1500 hwfeatures=36 lladdr X:X:X:X:X:X priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (1000baseT full-duplex) status: active
Re: Calling all softdep lovers: This turns down the suck on softdep.
Just a followon for tech people - if you do use this and
hit a problem, I would very much appreciate your dmesg,
as well as from ddb, "ps" "trace" "show bcstats" and "show uvm".
-Bob
On Wed, Nov 07, 2012 at 10:35:03AM -0800, Mike Larkin wrote:
> On Wed, Nov 07, 2012 at 11:25:55AM -0700, Bob Beck wrote:
> > Hello tech@.
> >
> > I just committed some significant fixes to the buffer cache in -current.
> > (you want to look for version 1.139 of vfs_bio.c)
> >
> > If you have such a current kernel, you may wish to try the following
> > diff - it is a backout of a previous commit that emasculated softdep
> > in order to make is safe with our buffer cache at the time. With
> > version 1.139 of vfs_bio.c I believe this is no longer needed.
> >
> > I have done extensive testing with the diff below and beating up
> > softdep filesystems - it both works, and, actually can provide
> > significantly increased performance in some situations.
> >
> > You too may want to try what is below. If you do, please drop me a
> > note indicating what you were doing with it, and what you noticed,
> > sucesses, failures, performance changes, etc. I would like to know
> > about all.
> >
> > WARNING - if you apply this to something without version 1.139 of
> > vfs_bio.c, you may hang your machine.
> >
> > Thanks
> >
> > -Bob
> >
>
> Been running on my main dev machine for the past day or so, no regressions
> seen. (Note I'm referring to the previous version of the diff circulated).
>
> -ml
>
> >
> > ---8<
> > Index: ufs/ffs/ffs_inode.c
> > ===
> > RCS file: /cvs/src/sys/ufs/ffs/ffs_inode.c,v
> > retrieving revision 1.61
> > diff -u -p -r1.61 ffs_inode.c
> > --- ufs/ffs/ffs_inode.c 23 Mar 2012 15:51:26 - 1.61
> > +++ ufs/ffs/ffs_inode.c 20 Sep 2012 13:27:05 -
> > @@ -164,10 +164,8 @@ ffs_truncate(struct inode *oip, off_t le
> > struct buf *bp;
> > int offset, size, level;
> > long count, nblocks, vflags, blocksreleased = 0;
> > - int i, aflags, error, allerror, indirect = 0;
> > + int i, aflags, error, allerror;
> > off_t osize;
> > - extern int num_indirdep;
> > - extern int max_indirdep;
> >
> > if (length < 0)
> > return (EINVAL);
> > @@ -243,8 +241,6 @@ ffs_truncate(struct inode *oip, off_t le
> >cred, aflags, &bp);
> > if (error)
> > return (error);
> > - if (bp->b_lblkno >= NDADDR)
> > - indirect = 1;
> > DIP_ASSIGN(oip, size, length);
> > uvm_vnp_setsize(ovp, length);
> > (void) uvm_vnp_uncache(ovp);
> > @@ -253,20 +249,7 @@ ffs_truncate(struct inode *oip, off_t le
> > else
> > bawrite(bp);
> > oip->i_flag |= IN_CHANGE | IN_UPDATE;
> > - error = UFS_UPDATE(oip, MNT_WAIT);
> > - if (DOINGSOFTDEP(ovp) && num_indirdep > max_indirdep)
> > - if (indirect) {
> > - /*
> > -* If the number of pending indirect block
> > -* dependencies is sufficiently close to the
> > -* maximum number of simultaneously mappable
> > -* buffers force a sync on the vnode to prevent
> > -* buffer cache exhaustion.
> > -*/
> > - VOP_FSYNC(ovp, curproc->p_ucred, MNT_WAIT,
> > - curproc);
> > - }
> > - return (error);
> > + return (UFS_UPDATE(oip, MNT_WAIT));
> > }
> > uvm_vnp_setsize(ovp, length);
> >
> > Index: ufs/ffs/ffs_softdep.c
> > ===
> > RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
> > retrieving revision 1.112
> > diff -u -p -r1.112 ffs_softdep.c
> > --- ufs/ffs/ffs_softdep.c 18 Sep 2011 23:20:28 - 1.112
> > +++ ufs/ffs/ffs_softdep.c 20 Sep 2012 13:27:05 -
> > @@ -526,8 +526,6 @@ workitem_free(struct worklist *item)
> > STATIC struct workhead softdep_workitem_pending;
> > STATIC struct worklist *worklist_tail;
> > STATIC int num_on_worklist;/* number of worklist items to be
> > processed */
> > -STATIC int num_indirdep; /* number of indirdep items to be processed */
> > -STATIC int max_indirdep; /* maximum number of indirdep items allowed */
> > STATIC int softdep_worklist_busy; /* 1 => trying to do unmount */
> > STATIC int softdep_worklist_req; /* serialized waiters */
> > STATIC int max_softdeps; /* maximum number of structs before slowdown */
> > @@ -1142,8 +1140,6 @@ top:
> > void
> > softdep_initialize(void)
> > {
> > - extern vsize_t bufkvm;
> > - max_indirdep = (int)bufkvm / MAXPHYS * 80 / 100;
> >
> > bioops.io_start = softdep_disk_io_initiation;
> >
Re: upstream vendors and why they can be really harmful
> and if you come with proper arguments (and code) they will be more than > happy to include it or change the way they do things to accomodate to > standards. Lennart is a different matter, he made it clear he doesn't > care about the rest of the ecosystem. But he is just one guy and his > lobbying works also because no one else is here to challenge him. It's > one thing to rant on mailing list and blobs... I know Lennart comes out with some right rubbish and utterly pointless and misleading hype from this link but whether he is pulling strings I do not know and in any case does not change the facts. http://0pointer.de/blog/projects/security.html It's stated time and again that if you are a Linux distro you will have to switch to systemd sooner or later. It was even said on this list debian will switch without giving evidence, was it the hype?. I welcome any recent links to contradict me? You get a similar thing in football, if some say someones the best defender enough times, even if they are judging him on his shooting ability then many believe it. Something that's cost England dearly. The limited decision process I saw from the debian leader said let's wait ten years and consider openrc in the meantime and it wasn't just because debian has BSD interests. http://lwn.net/Articles/512719/ Aside from systemd being slated technically on the Gentoo and also the Sabayon lists (http://lists.sabayon.org/pipermail/devel/2012-August/008278.html) Gentoo have said something like, we are about freedom and as systemd is curtailing that we are more likely to drop Gnome than support a default of systemd. Of course as choice is our main goal we hope systemd will run too, it will just be unsupported. As I have said I don't think anyone knows the figure but if Gnome becomes dependent on systemd, they are isolating most of their potential user base provided by Debian, Ubuntu and Gentoo and it's livecd derivitives and sending half their users over to the likes of KDE/XFCE that have already gnudged ahead. The only distros with a fair few users who have switched and still have far less users are Fedora, Mageia and OpenSUSE. So there are many many annoyed by this and it should hit true, especially as KDE has apparently already overtaken Gnome as the most used desktop. I just hope you get your answer sooner but from Gnomes recent record, I'd be worried too, so Good luck and keep us informed please. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: Calling all softdep lovers: This turns down the suck on softdep.
On Wed, Nov 07, 2012 at 11:25:55AM -0700, Bob Beck wrote:
> Hello tech@.
>
> I just committed some significant fixes to the buffer cache in -current.
> (you want to look for version 1.139 of vfs_bio.c)
>
> If you have such a current kernel, you may wish to try the following
> diff - it is a backout of a previous commit that emasculated softdep
> in order to make is safe with our buffer cache at the time. With
> version 1.139 of vfs_bio.c I believe this is no longer needed.
>
> I have done extensive testing with the diff below and beating up
> softdep filesystems - it both works, and, actually can provide
> significantly increased performance in some situations.
>
> You too may want to try what is below. If you do, please drop me a
> note indicating what you were doing with it, and what you noticed,
> sucesses, failures, performance changes, etc. I would like to know
> about all.
>
> WARNING - if you apply this to something without version 1.139 of
> vfs_bio.c, you may hang your machine.
>
> Thanks
>
> -Bob
>
Been running on my main dev machine for the past day or so, no regressions
seen. (Note I'm referring to the previous version of the diff circulated).
-ml
>
> ---8<
> Index: ufs/ffs/ffs_inode.c
> ===
> RCS file: /cvs/src/sys/ufs/ffs/ffs_inode.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 ffs_inode.c
> --- ufs/ffs/ffs_inode.c 23 Mar 2012 15:51:26 - 1.61
> +++ ufs/ffs/ffs_inode.c 20 Sep 2012 13:27:05 -
> @@ -164,10 +164,8 @@ ffs_truncate(struct inode *oip, off_t le
> struct buf *bp;
> int offset, size, level;
> long count, nblocks, vflags, blocksreleased = 0;
> - int i, aflags, error, allerror, indirect = 0;
> + int i, aflags, error, allerror;
> off_t osize;
> - extern int num_indirdep;
> - extern int max_indirdep;
>
> if (length < 0)
> return (EINVAL);
> @@ -243,8 +241,6 @@ ffs_truncate(struct inode *oip, off_t le
> cred, aflags, &bp);
> if (error)
> return (error);
> - if (bp->b_lblkno >= NDADDR)
> - indirect = 1;
> DIP_ASSIGN(oip, size, length);
> uvm_vnp_setsize(ovp, length);
> (void) uvm_vnp_uncache(ovp);
> @@ -253,20 +249,7 @@ ffs_truncate(struct inode *oip, off_t le
> else
> bawrite(bp);
> oip->i_flag |= IN_CHANGE | IN_UPDATE;
> - error = UFS_UPDATE(oip, MNT_WAIT);
> - if (DOINGSOFTDEP(ovp) && num_indirdep > max_indirdep)
> - if (indirect) {
> - /*
> - * If the number of pending indirect block
> - * dependencies is sufficiently close to the
> - * maximum number of simultaneously mappable
> - * buffers force a sync on the vnode to prevent
> - * buffer cache exhaustion.
> - */
> - VOP_FSYNC(ovp, curproc->p_ucred, MNT_WAIT,
> - curproc);
> - }
> - return (error);
> + return (UFS_UPDATE(oip, MNT_WAIT));
> }
> uvm_vnp_setsize(ovp, length);
>
> Index: ufs/ffs/ffs_softdep.c
> ===
> RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 ffs_softdep.c
> --- ufs/ffs/ffs_softdep.c 18 Sep 2011 23:20:28 - 1.112
> +++ ufs/ffs/ffs_softdep.c 20 Sep 2012 13:27:05 -
> @@ -526,8 +526,6 @@ workitem_free(struct worklist *item)
> STATIC struct workhead softdep_workitem_pending;
> STATIC struct worklist *worklist_tail;
> STATIC int num_on_worklist; /* number of worklist items to be processed */
> -STATIC int num_indirdep; /* number of indirdep items to be processed */
> -STATIC int max_indirdep; /* maximum number of indirdep items allowed */
> STATIC int softdep_worklist_busy; /* 1 => trying to do unmount */
> STATIC int softdep_worklist_req; /* serialized waiters */
> STATIC int max_softdeps; /* maximum number of structs before slowdown */
> @@ -1142,8 +1140,6 @@ top:
> void
> softdep_initialize(void)
> {
> - extern vsize_t bufkvm;
> - max_indirdep = (int)bufkvm / MAXPHYS * 80 / 100;
>
> bioops.io_start = softdep_disk_io_initiation;
> bioops.io_complete = softdep_disk_write_complete;
> @@ -1819,14 +1815,12 @@ setup_allocindir_phase2(struct buf *bp,
> if (indirdep->ir_savebp != NULL)
> brelse(newindirdep->ir_savebp);
> WORKITEM_FREE(newindirdep, D_INDIRDEP);
> - num_indirdep--;
> }
> if (
Calling all softdep lovers: This turns down the suck on softdep.
Hello tech@.
I just committed some significant fixes to the buffer cache in -current.
(you want to look for version 1.139 of vfs_bio.c)
If you have such a current kernel, you may wish to try the following
diff - it is a backout of a previous commit that emasculated softdep
in order to make is safe with our buffer cache at the time. With
version 1.139 of vfs_bio.c I believe this is no longer needed.
I have done extensive testing with the diff below and beating up
softdep filesystems - it both works, and, actually can provide
significantly increased performance in some situations.
You too may want to try what is below. If you do, please drop me a
note indicating what you were doing with it, and what you noticed,
sucesses, failures, performance changes, etc. I would like to know
about all.
WARNING - if you apply this to something without version 1.139 of
vfs_bio.c, you may hang your machine.
Thanks
-Bob
---8<
Index: ufs/ffs/ffs_inode.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_inode.c,v
retrieving revision 1.61
diff -u -p -r1.61 ffs_inode.c
--- ufs/ffs/ffs_inode.c 23 Mar 2012 15:51:26 - 1.61
+++ ufs/ffs/ffs_inode.c 20 Sep 2012 13:27:05 -
@@ -164,10 +164,8 @@ ffs_truncate(struct inode *oip, off_t le
struct buf *bp;
int offset, size, level;
long count, nblocks, vflags, blocksreleased = 0;
- int i, aflags, error, allerror, indirect = 0;
+ int i, aflags, error, allerror;
off_t osize;
- extern int num_indirdep;
- extern int max_indirdep;
if (length < 0)
return (EINVAL);
@@ -243,8 +241,6 @@ ffs_truncate(struct inode *oip, off_t le
cred, aflags, &bp);
if (error)
return (error);
- if (bp->b_lblkno >= NDADDR)
- indirect = 1;
DIP_ASSIGN(oip, size, length);
uvm_vnp_setsize(ovp, length);
(void) uvm_vnp_uncache(ovp);
@@ -253,20 +249,7 @@ ffs_truncate(struct inode *oip, off_t le
else
bawrite(bp);
oip->i_flag |= IN_CHANGE | IN_UPDATE;
- error = UFS_UPDATE(oip, MNT_WAIT);
- if (DOINGSOFTDEP(ovp) && num_indirdep > max_indirdep)
- if (indirect) {
- /*
-* If the number of pending indirect block
-* dependencies is sufficiently close to the
-* maximum number of simultaneously mappable
-* buffers force a sync on the vnode to prevent
-* buffer cache exhaustion.
-*/
- VOP_FSYNC(ovp, curproc->p_ucred, MNT_WAIT,
- curproc);
- }
- return (error);
+ return (UFS_UPDATE(oip, MNT_WAIT));
}
uvm_vnp_setsize(ovp, length);
Index: ufs/ffs/ffs_softdep.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.112
diff -u -p -r1.112 ffs_softdep.c
--- ufs/ffs/ffs_softdep.c 18 Sep 2011 23:20:28 - 1.112
+++ ufs/ffs/ffs_softdep.c 20 Sep 2012 13:27:05 -
@@ -526,8 +526,6 @@ workitem_free(struct worklist *item)
STATIC struct workhead softdep_workitem_pending;
STATIC struct worklist *worklist_tail;
STATIC int num_on_worklist;/* number of worklist items to be processed */
-STATIC int num_indirdep; /* number of indirdep items to be processed */
-STATIC int max_indirdep; /* maximum number of indirdep items allowed */
STATIC int softdep_worklist_busy; /* 1 => trying to do unmount */
STATIC int softdep_worklist_req; /* serialized waiters */
STATIC int max_softdeps; /* maximum number of structs before slowdown */
@@ -1142,8 +1140,6 @@ top:
void
softdep_initialize(void)
{
- extern vsize_t bufkvm;
- max_indirdep = (int)bufkvm / MAXPHYS * 80 / 100;
bioops.io_start = softdep_disk_io_initiation;
bioops.io_complete = softdep_disk_write_complete;
@@ -1819,14 +1815,12 @@ setup_allocindir_phase2(struct buf *bp,
if (indirdep->ir_savebp != NULL)
brelse(newindirdep->ir_savebp);
WORKITEM_FREE(newindirdep, D_INDIRDEP);
- num_indirdep--;
}
if (indirdep)
break;
newindirdep = pool_get(&indirdep_pool, PR_WAITOK);
newindirdep->ir_list.wk_type = D_INDIRDEP;
newindirdep->ir_state = ATTACHED;
- num_indirdep++;
if (ip->i_ump->um_fstype == UM_UFS1)
newindirdep->
Re: [PATCH 1/1] Window class and name both come from WM_CLASS property.
On Mon 2012.11.05 at 13:33 -0600, kspill...@acm.org wrote: > Explicitly mention that the values of class and name for use with autogroup > can both be obtained from the WM_CLASS property of existing windows. applied this one - thank you.
ix: IFCAP_CSUM flags are pointless for the rx checksums
Remove code that is confusing and wrong: we don't want to disable
rx checksumming if IFCAP_CSUM_IPv4 is set. Whatever this code used
to mean in FreeBSD it doesn't do any good here. IXGBE_RXCSUM_PCSD
is set when you do RSS (and is correctly handled in the visible RSS
chunk below).
OK?
Index: if_ix.c
===
RCS file: /cvs/openbsd/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.73
diff -u -p -r1.73 if_ix.c
--- if_ix.c 6 Nov 2012 17:29:39 - 1.73
+++ if_ix.c 7 Nov 2012 14:56:14 -
@@ -2826,6 +2826,7 @@ ixgbe_initialize_receive_units(struct ix
}
rxcsum = IXGBE_READ_REG(&sc->hw, IXGBE_RXCSUM);
+ rxcsum &= ~IXGBE_RXCSUM_PCSD;
/* Setup RSS */
if (sc->num_queues > 1) {
@@ -2863,9 +2864,6 @@ ixgbe_initialize_receive_units(struct ix
/* RSS and RX IPP Checksum are mutually exclusive */
rxcsum |= IXGBE_RXCSUM_PCSD;
}
-
- if (ifp->if_capabilities & IFCAP_CSUM_IPv4)
- rxcsum |= IXGBE_RXCSUM_PCSD;
if (!(rxcsum & IXGBE_RXCSUM_PCSD))
rxcsum |= IXGBE_RXCSUM_IPPCSE;
Re: em(4): enable TCP/UDP checksum offload
On Sun, 4 Nov 2012 16:06:31 +0100 Christopher Zimmermann wrote: > On Sun, 4 Nov 2012 14:46:34 +0100 > Stefan Sperling wrote: > > > On Sun, Nov 04, 2012 at 01:21:38PM +, Christian Weisgerber wrote: > > > Christian Weisgerber wrote: > > > > > > > Like bge(4), we previously couldn't enable TCP/UDP transmit checksum > > > > offload on em(4). We can now. > > > > > > > > Works fine here on > > > > em0 at pci1 dev 1 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02 > > > > and with VLAN on > > > > em0 at pci5 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00 > > > > > > It does however fail on > > > em0 at pci1 dev 0 function 0 "Intel I350" rev 0x01 > > > > > > (Watchdog timeouts, interface is unusable.) > > > > This one is working fine: > > em0 at pci1 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00 > > here too: > em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi and using it actively as NFS (udp) client.
Re: em(4): enable TCP/UDP checksum offload
On 5.11.2012 23:45, Hrvoje Popovski wrote: > On 5.11.2012. 14:38, Hrvoje Popovski wrote: >> >> Hello, >> >> it's working here. > > Please ignore "working here" part. It is enabled here. > Will play with combination of 82546GB and 82541GI interfaces. > 82546GB pf (with henning's patch) + ipforward and with or without em tcp/udp checksum - not working 82541GI pf (with henning's patch) + ipforward + em tcp/udp checksum - works like charm with 82546GB and openbsd as host things like ssh, dns (small traffic) works
Re: em(4): enable TCP/UDP checksum offload
On Wed, Nov 7, 2012 at 12:32 PM, Tomas Bodzar wrote: > Hi, > > somewhat strange results here > > $ ifconfig em0 hwfeatures > em0: flags=8843 mtu 1500 > hwfeatures=36 > lladdr XX:XX:XX:XX:XX:XX > priority: 0 > groups: egress > media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) > status: active > inet X.X.X.X netmask 0xff00 broadcast X.X.X.X > $ > > "Intel Q45 KT" rev 0x03 at pci0 dev 3 function 3 not configured > em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: msi, > address X:X:X:X:X:X > > I can ping gateway, I can ping various servers on Internet via IP or > DNS name, Apache from base running under chroot with HTTP and HTTPS > and blogsum provided via HTTP. I can ssh login to that machine, I can > view blogsum from remote machines, but localy on server xombrero or > lynx is not able to display ANY web page, not even from local Apache. > > > On VMware Player 5 it seems to be fine including SSH, cvs, webbrowsing, pf for desktop use, remote X $ ifconfig em0 hwfeatures em0: flags=8843 mtu 1500 hwfeatures=36 lladdr X:X:X:X:X:X priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet X.X.X.X netmask 0xff00 broadcast X.X.X.X $ em0 at pci2 dev 0 function 0 "Intel PRO/1000MT (82545EM)" rev 0x01: apic 1 int 18, address X:X:X:X:X:X > > On Wed, Nov 7, 2012 at 8:50 AM, mxb wrote: >> In my case, >> it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre >> on top of ipsec, running npppd, >> and daily NAT/RDR for about 100 clients. >> >> On 6 nov 2012, at 21:31, Stuart Henderson wrote: >> >>> For people who are testing checksum-offload-enabling diffs, it would >>> help if you could say what sort of things have tested. Things like >>> fragments/NFS are far more likely to exercise bugs in the hardware >>> than standard web browsing.
Re: em(4): enable TCP/UDP checksum offload
Hi, somewhat strange results here $ ifconfig em0 hwfeatures em0: flags=8843 mtu 1500 hwfeatures=36 lladdr XX:XX:XX:XX:XX:XX priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet X.X.X.X netmask 0xff00 broadcast X.X.X.X $ "Intel Q45 KT" rev 0x03 at pci0 dev 3 function 3 not configured em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: msi, address X:X:X:X:X:X I can ping gateway, I can ping various servers on Internet via IP or DNS name, Apache from base running under chroot with HTTP and HTTPS and blogsum provided via HTTP. I can ssh login to that machine, I can view blogsum from remote machines, but localy on server xombrero or lynx is not able to display ANY web page, not even from local Apache. On Wed, Nov 7, 2012 at 8:50 AM, mxb wrote: > In my case, > it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre > on top of ipsec, running npppd, > and daily NAT/RDR for about 100 clients. > > On 6 nov 2012, at 21:31, Stuart Henderson wrote: > >> For people who are testing checksum-offload-enabling diffs, it would >> help if you could say what sort of things have tested. Things like >> fragments/NFS are far more likely to exercise bugs in the hardware >> than standard web browsing.
Re: PATCH: Virtio memory balooning
Ok, so I added the required line to amd64 GENERIC and ran a KVM guest
with it, dmesg now says:
virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Memory" rev 0x00:
Virtio Memory Balloon Device
viomb0 at virtio1
virtio1: apic 1 int 10
Dont think I have enough shiny GUIs to monitor ballooning stats, but
I'll see if I can dig something up on the host machine.
2012/11/7 Janne Johansson :
> Any reason for this being i386 or just not tested on virtual amd64s?
>
> 2012/11/6 Dinar Talypov :
>> Hi,
>> This patch adds virtio memory ballooning device support.
>> Actually code was taken from NetBSD and I rewrote some
>> OpenBSD specific parts.
>>
>
>
>
>> +static const struct virtio_feature_name viomb_feature_names[] = {
>> + {VIRTIO_BALLOON_F_MUST_TELL_HOST, "TellHost"},
>> + {VIRTIO_BALLOON_F_STATS_VQ, "StatVQ"},
>> + {0, NULL}
>> +};
>> +#define PGS_PER_REQ256 /* 1MB, 4KB/page */
>
> ---cut--
>
>> +
>> +#define PGS_PER_REQ256 /* 1MB, 4KB/page */
>> +
>
> Small nit, but this appears twice.
>
>
> --
> To our sweethearts and wives. May they never meet. -- 19th century toast
--
To our sweethearts and wives. May they never meet. -- 19th century toast
Re: PATCH: Virtio memory balooning
Any reason for this being i386 or just not tested on virtual amd64s?
2012/11/6 Dinar Talypov :
> Hi,
> This patch adds virtio memory ballooning device support.
> Actually code was taken from NetBSD and I rewrote some
> OpenBSD specific parts.
>
> +static const struct virtio_feature_name viomb_feature_names[] = {
> + {VIRTIO_BALLOON_F_MUST_TELL_HOST, "TellHost"},
> + {VIRTIO_BALLOON_F_STATS_VQ, "StatVQ"},
> + {0, NULL}
> +};
> +#define PGS_PER_REQ256 /* 1MB, 4KB/page */
---cut--
> +
> +#define PGS_PER_REQ256 /* 1MB, 4KB/page */
> +
Small nit, but this appears twice.
--
To our sweethearts and wives. May they never meet. -- 19th century toast
