Re: ld.so speedup (part 2)
On Mon, Apr 29 2019, Stuart Henderson wrote: > On 2019/04/28 09:45, Brian Callahan wrote: >> >> >> On 4/28/19 6:01 AM, Matthieu Herrb wrote: >> > On Sun, Apr 28, 2019 at 08:55:16AM +0100, Stuart Henderson wrote: >> > > > > > > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote: >> > > > > > > > The diff below speeds up ld.so library intialisation where the >> > > > > > dependency >> > > > > > > > tree is broad and deep, such as samba's smbd which links over >> > > > > > > > 100 >> > > > > > libraries. >> > > Past experience with ld.so changes suggests it would be good to have >> > > test reports from multiple arches, *especially* hppa. >> > The regress test seem to pass here on hppa. >> > >> >> Pass here too on hppa and macppc and armv7. >> >> ~Brian >> > > Regress is clean for me on i386 and I am using it on my current ports bulk > build there (halfway done, no issues seen yet). Using this in current ports bulk on sparc64, no fallout. > Regress is also clean on arm64. and on sparc64. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: make kevent(2) (a bit) mpsafe
On Wed, May 01, 2019 at 04:35:02PM +1000, David Gwynne wrote: > i originally came at this from the other side, where i wanted to run > kqueue_enqueue and _dequeue without the KERNEL_LOCK, but that implied > making kqueue_scan use the mutex too, which allowed the syscall to > become less locked. > > it assumes that the existing locking in kqueue_scan is in the right > place, it just turns it into a mutex instead of KERNEL_LOCK with > splhigh. it leaves the kqueue_register code under KERNEL_LOCK, but if > you're not making changes with kevent then this should be a win. > > there's an extra rwlock around the kqueue_scan call. this protects the > kq_head list from having multiple marker structs attached to it. that is > an extremely rare situation, ie, you'd have to have two threads execute > kevent on the same kq fd concurrently, but that never happens. right? FWIW, in Linux-land a shared event descriptor with edge-triggered events is a not uncommon pattern for multithreaded dispatch loops as it removes the need for userspace locking. kqueue supports the same pattern and some portable event loops likely mix threads and shared event descriptors this way. epoll and kqueue (and Solaris Ports, for that matter) are similar enough that a thin wrapper doesn't even need to explicitly support this pattern for it to be available to an application. I don't see any reason to optimize for it at the moment though.[1] That lock doesn't appear to change semantics, just serializes threads waiting on the queue, right? Even if the order that threads are awoken changes it shouldn't impact correctness. [1] Or ever. Edge-triggered events and shared mutable data are individually brittle, difficult to maintain design choices; combining them is just asking for trouble. I've seen projects go down this path and then switch to oneshot events instead of edge-triggered events to "solve" thread race bugs, which can result in worse performance than a classic select loop. For example, in low-latency and/or high load scenarios where the total number of syscalls constantly rearming a descriptor is greater. Linux still doesn't have batched updates, AFAIK, and they're prohibitively difficult to implement for a multithreaded, lock-free dispatch loop, anyhow, so it's not a common optimization.
Re: ccp(4) support for AMD Ryzen 3 PRO 2200GE
On Wed, May 01, 2019 at 06:26:49PM +0200, Mark Kettenis wrote:
> Linux doesn't have this yet, so this is pure guesswork, and I pulled
> the name out of my ass. But the numbers I get look random enough.
>
> ok?
>
Sure, ok mlarkin if you didn't commit already
> P.S. I think it would make sense to rename the device IDs and the
> strings to be similar to their companions on the chip. I'll send
> out a separate diff for that.
>
>
> Index: dev/pci/ccp_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ccp_pci.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 ccp_pci.c
> --- dev/pci/ccp_pci.c 20 Apr 2018 04:37:21 - 1.1
> +++ dev/pci/ccp_pci.c 1 May 2019 16:18:47 -
> @@ -46,6 +46,7 @@ static const struct pci_matchid ccp_pci_
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV3 },
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5A },
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5B },
> + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5C },
> };
>
> int
> Index: dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1885
> diff -u -p -r1.1885 pcidevs
> --- dev/pci/pcidevs 24 Apr 2019 03:44:50 - 1.1885
> +++ dev/pci/pcidevs 1 May 2019 16:18:47 -
> @@ -790,6 +790,7 @@ product AMD AMD64_17_1X_IOMMU 0x15d1 AMD
> product AMD AMD64_17_1X_PCIE_1 0x15d3 AMD64 17h/1xh PCIE
> product AMD AMD64_17_1X_PCIE_2 0x15db AMD64 17h/1xh PCIE
> product AMD AMD64_17_1X_PCIE_3 0x15dc AMD64 17h/1xh PCIE
> +product AMD CCPV5C 0x15df Cryptographic Co-processor v5c
> product AMD AMD64_17_1X_XHCI_1 0x15e0 AMD64 17h/1xh xHCI
> product AMD AMD64_17_1X_XHCI_2 0x15e1 AMD64 17h/1xh xHCI
> product AMD RAVENRIDGE_HDA 0x15e3 Raven Ridge HD Audio
> Index: dev/pci/pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1878
> diff -u -p -r1.1878 pcidevs.h
> --- dev/pci/pcidevs.h 24 Apr 2019 03:45:35 - 1.1878
> +++ dev/pci/pcidevs.h 1 May 2019 16:18:47 -
> @@ -795,6 +795,7 @@
> #define PCI_PRODUCT_AMD_AMD64_17_1X_PCIE_1 0x15d3 /*
> AMD64 17h/1xh PCIE */
> #define PCI_PRODUCT_AMD_AMD64_17_1X_PCIE_2 0x15db /*
> AMD64 17h/1xh PCIE */
> #define PCI_PRODUCT_AMD_AMD64_17_1X_PCIE_3 0x15dc /*
> AMD64 17h/1xh PCIE */
> +#define PCI_PRODUCT_AMD_CCPV5C 0x15df /* Cryptographic
> Co-processor v5c */
> #define PCI_PRODUCT_AMD_AMD64_17_1X_XHCI_1 0x15e0 /*
> AMD64 17h/1xh xHCI */
> #define PCI_PRODUCT_AMD_AMD64_17_1X_XHCI_2 0x15e1 /*
> AMD64 17h/1xh xHCI */
> #define PCI_PRODUCT_AMD_RAVENRIDGE_HDA 0x15e3 /* Raven Ridge
> HD Audio */
> Index: dev/pci/pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1873
> diff -u -p -r1.1873 pcidevs_data.h
> --- dev/pci/pcidevs_data.h24 Apr 2019 03:45:35 - 1.1873
> +++ dev/pci/pcidevs_data.h1 May 2019 16:18:47 -
> @@ -1512,6 +1512,10 @@ static const struct pci_known_product pc
> "AMD64 17h/1xh PCIE",
> },
> {
> + PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5C,
> + "Cryptographic Co-processor v5c",
> + },
> + {
> PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_XHCI_1,
> "AMD64 17h/1xh xHCI",
> },
>
ccp(4) support for AMD Ryzen 3 PRO 2200GE
Linux doesn't have this yet, so this is pure guesswork, and I pulled
the name out of my ass. But the numbers I get look random enough.
ok?
P.S. I think it would make sense to rename the device IDs and the
strings to be similar to their companions on the chip. I'll send
out a separate diff for that.
Index: dev/pci/ccp_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ccp_pci.c,v
retrieving revision 1.1
diff -u -p -r1.1 ccp_pci.c
--- dev/pci/ccp_pci.c 20 Apr 2018 04:37:21 - 1.1
+++ dev/pci/ccp_pci.c 1 May 2019 16:18:47 -
@@ -46,6 +46,7 @@ static const struct pci_matchid ccp_pci_
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV3 },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5A },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5B },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5C },
};
int
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1885
diff -u -p -r1.1885 pcidevs
--- dev/pci/pcidevs 24 Apr 2019 03:44:50 - 1.1885
+++ dev/pci/pcidevs 1 May 2019 16:18:47 -
@@ -790,6 +790,7 @@ product AMD AMD64_17_1X_IOMMU 0x15d1 AMD
product AMD AMD64_17_1X_PCIE_1 0x15d3 AMD64 17h/1xh PCIE
product AMD AMD64_17_1X_PCIE_2 0x15db AMD64 17h/1xh PCIE
product AMD AMD64_17_1X_PCIE_3 0x15dc AMD64 17h/1xh PCIE
+product AMD CCPV5C 0x15df Cryptographic Co-processor v5c
product AMD AMD64_17_1X_XHCI_1 0x15e0 AMD64 17h/1xh xHCI
product AMD AMD64_17_1X_XHCI_2 0x15e1 AMD64 17h/1xh xHCI
product AMD RAVENRIDGE_HDA 0x15e3 Raven Ridge HD Audio
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1878
diff -u -p -r1.1878 pcidevs.h
--- dev/pci/pcidevs.h 24 Apr 2019 03:45:35 - 1.1878
+++ dev/pci/pcidevs.h 1 May 2019 16:18:47 -
@@ -795,6 +795,7 @@
#definePCI_PRODUCT_AMD_AMD64_17_1X_PCIE_1 0x15d3 /*
AMD64 17h/1xh PCIE */
#definePCI_PRODUCT_AMD_AMD64_17_1X_PCIE_2 0x15db /*
AMD64 17h/1xh PCIE */
#definePCI_PRODUCT_AMD_AMD64_17_1X_PCIE_3 0x15dc /*
AMD64 17h/1xh PCIE */
+#definePCI_PRODUCT_AMD_CCPV5C 0x15df /* Cryptographic
Co-processor v5c */
#definePCI_PRODUCT_AMD_AMD64_17_1X_XHCI_1 0x15e0 /*
AMD64 17h/1xh xHCI */
#definePCI_PRODUCT_AMD_AMD64_17_1X_XHCI_2 0x15e1 /*
AMD64 17h/1xh xHCI */
#definePCI_PRODUCT_AMD_RAVENRIDGE_HDA 0x15e3 /* Raven Ridge
HD Audio */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1873
diff -u -p -r1.1873 pcidevs_data.h
--- dev/pci/pcidevs_data.h 24 Apr 2019 03:45:35 - 1.1873
+++ dev/pci/pcidevs_data.h 1 May 2019 16:18:47 -
@@ -1512,6 +1512,10 @@ static const struct pci_known_product pc
"AMD64 17h/1xh PCIE",
},
{
+ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_CCPV5C,
+ "Cryptographic Co-processor v5c",
+ },
+ {
PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_XHCI_1,
"AMD64 17h/1xh xHCI",
},
Re: [PATCH] cwm window center functionality
I'd prefer if centering were a seperate function to resizing to a fraction of the screen size, as I'd like to be able to center a window *after* resizing it to my liking. x11/xdotool could be used by anybody needing the resizing functionality, for example, bind-key 4-r "xdotool getactivewindow windowsize 50% 50%" The fraction of the screen taken up would then be configurable, without having to add another option. Cheers, Joe
Re: unveil tcpdrop
On Tue, Apr 30, 2019 at 06:23:57PM +0100, Ricardo Mestre wrote:
> Went through my old sent emails and saw this one still pending on my tree.
>
> Is this OK?
>
> On 13:02 Wed 07 Nov , Ricardo Mestre wrote:
> > Hi,
> >
> > tcpdrop(8) needs to access only two files, in this case /etc/hosts and
> > /etc/resolv.conf both with read permissions for the purpose of name
> > resolution.
> > ethers(5) is not needed since we are not using any of the ether_*(3) family.
> >
> > Since unistd.h needs to be included I also shuffled netdb.h into the right
> > place.
> >
> > Comments? OK?
> >
> > Index: tcpdrop.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdrop/tcpdrop.c,v
> > retrieving revision 1.17
> > diff -u -p -u -r1.17 tcpdrop.c
> > --- tcpdrop.c 16 Jan 2015 06:40:21 - 1.17
> > +++ tcpdrop.c 6 Nov 2018 10:48:10 -
> > @@ -27,10 +27,11 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > -#include
> > +#include
> >
> > __dead void usage(void);
> >
> > @@ -61,6 +62,13 @@ main(int argc, char **argv)
> > char *laddr1, *addr1, *port1, *faddr2, *addr2, *port2;
> > struct tcp_ident_mapping tir;
> > int gaierr, rval = 0;
> > +
> > + if (unveil("/etc/hosts", "r") == -1)
> > + err(1, "unveil");
> > + if (unveil("/etc/resolv.conf", "r") == -1)
> > + err(1, "unveil");
> > + if (unveil(NULL, NULL) == -1)
> > + err(1, "unveil");
> >
> > memset(&hints, 0, sizeof(hints));
> > hints.ai_family = AF_UNSPEC;
This seems low risk, and looks good to me also.
ok brynet@
Re: make kevent(2) (a bit) mpsafe
On 01/05/19(Wed) 16:35, David Gwynne wrote:
> i originally came at this from the other side, where i wanted to run
> kqueue_enqueue and _dequeue without the KERNEL_LOCK, but that implied
> making kqueue_scan use the mutex too, which allowed the syscall to
> become less locked.
>
> it assumes that the existing locking in kqueue_scan is in the right
> place, it just turns it into a mutex instead of KERNEL_LOCK with
> splhigh. it leaves the kqueue_register code under KERNEL_LOCK, but if
> you're not making changes with kevent then this should be a win.
>
> there's an extra rwlock around the kqueue_scan call. this protects the
> kq_head list from having multiple marker structs attached to it. that is
> an extremely rare situation, ie, you'd have to have two threads execute
> kevent on the same kq fd concurrently, but that never happens. right?
If you look at the archives on bugs@ that can happen. The diff that has
been backed out exposed an issue possibly related to multiple threads
playing with the queue.
> it seems to work ok, but i havent tested it extensively.
>
> thoughts?
I believe removing the KERNEL_LOCK() from the syscall should be done in a
second step, see below.
> @@ -796,10 +810,12 @@ start:
> nkev++;
> if (kn->kn_flags & EV_ONESHOT) {
> kn->kn_status &= ~KN_QUEUED;
> - splx(s);
> + mtx_leave(&kq->kq_mtx);
> + KERNEL_LOCK();
> kn->kn_fop->f_detach(kn);
> + KERNEL_UNLOCK();
> knote_drop(kn, p);
> - s = splhigh();
> + mtx_enter(&kq->kq_mtx);
By releasing the mutex here aren't we allowing multiple callers to play
with the queue? Is it safe? Does that mean that another thread might
ends up removing the existing marker?
Please look at my previous change "Make it possible for multiple
threads to enter kqueue_scan() in parallel" which is based on the
approach taken by Dfly. I believe there's many more dragons in there
:o)
Re: unveil tcpdrop
Ricardo Mestre(ser...@helheim.mooo.com) on 2019.04.30 18:23:57 +0100:
> Went through my old sent emails and saw this one still pending on my tree.
>
> Is this OK?
you got an
OK bluhm@
on Nov 7th.
and since i cant see a problem with it, ok benno@ too ;)
> On 13:02 Wed 07 Nov , Ricardo Mestre wrote:
> > Hi,
> >
> > tcpdrop(8) needs to access only two files, in this case /etc/hosts and
> > /etc/resolv.conf both with read permissions for the purpose of name
> > resolution.
> > ethers(5) is not needed since we are not using any of the ether_*(3) family.
> >
> > Since unistd.h needs to be included I also shuffled netdb.h into the right
> > place.
> >
> > Comments? OK?
> >
> > Index: tcpdrop.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdrop/tcpdrop.c,v
> > retrieving revision 1.17
> > diff -u -p -u -r1.17 tcpdrop.c
> > --- tcpdrop.c 16 Jan 2015 06:40:21 - 1.17
> > +++ tcpdrop.c 6 Nov 2018 10:48:10 -
> > @@ -27,10 +27,11 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > -#include
> > +#include
> >
> > __dead void usage(void);
> >
> > @@ -61,6 +62,13 @@ main(int argc, char **argv)
> > char *laddr1, *addr1, *port1, *faddr2, *addr2, *port2;
> > struct tcp_ident_mapping tir;
> > int gaierr, rval = 0;
> > +
> > + if (unveil("/etc/hosts", "r") == -1)
> > + err(1, "unveil");
> > + if (unveil("/etc/resolv.conf", "r") == -1)
> > + err(1, "unveil");
> > + if (unveil(NULL, NULL) == -1)
> > + err(1, "unveil");
> >
> > memset(&hints, 0, sizeof(hints));
> > hints.ai_family = AF_UNSPEC;
>
Re: libevent: remove non-monotonic compat code
On Tue, Apr 30, 2019 at 07:13:55PM +0200, Jeremie Courreges-Anglas wrote: > > So the diff below removes the fallback path and all associated code and > > variables. > > > I have left out some minor cleanups for now to ease reviews. > > Here's a diff that amends the signature of gettime() and makes use of > TIMESPEC_TO_TIMEVAL(). Okay for both.
