Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On 7 Jul, Alexey Dokuchaev wrote: > On Fri, Jul 06, 2018 at 05:06:03PM -0700, Don Lewis wrote: >> The other machine is my Pentium-M laptop, which is mostly used for light >> browsing and as a VNC client when I'm on the road. Performance is >> acceptable for those uses. Both machines run stripped down UP kernels to >> avoid wasting RAM unnecessarily and to optimize CPU cycles on the laptop. >> >> [...] I've managed to commit changes that break UP builds and not known >> it until I received reports of broken builds from other users. > > :-) That's funny: you run custom UP kernels, and yet managed to break UP > builds with the breakage being unknown to you until you received reports > from other users, lol. Yeah, definitely ironic ... The Via machine basically only gets security updates. With only 256 MB of RAM, it's probably too wimpy to self-host, and I hate to think about how long buildworld would take. I cross build releases on a more modern machine and use a custom freebsd-update to keep it up to date, with itself is a PITA. I think packaged base would be less of a hassle. The laptop gets more frequent updates and is able to self-host. Doing buildworld + buildkernel takes a really long time. It looks like my last buildworld (11-STABLE) took nearly 14 hours. This was my fastest machine for quite a while. I'm planning on doing an update this weekend in preparation for an upcoming trip. > On a related note, did you measure how much (e.g. in terms of battery > life) your laptop gains from using the UP kernel? Could you also share > your config? I'm using Pentium-M laptop as my primary machine as well, > and always eager to squeeze something more out of it. Thanks, I don't have any data for battery life. Almost all of my usage is with line power. Config file: include GENERIC nooptions SMP nodeviceahci nodevicemvs nodevicesiis nodeviceahc nodeviceahd nodeviceesp nodevicehptiop nodeviceisp nodevicempt nodevicemps nodevicempr nodevicencr nodevicesym nodevicetrm nodeviceadv nodeviceadw nodeviceaha nodeviceaic nodevicebt nodevicencv nodevicensp nodevicestg nodeviceisci nodevicech nodeviceses nodevicectl nodeviceamr nodevicearcmsr nodeviceasr nodeviceciss nodevicedpt nodevicehptmv nodevicehptnr nodevicehptrr nodevicehpt27xx nodeviceiir nodeviceips nodevicemly nodevicetwa nodevicetws nodeviceaac nodeviceaacp nodeviceaacraid nodeviceida nodevicemfi nodevicemlx nodevicemrsas nodevicepmspcv nodevicepst nodevicetwe nodevicenvme nodevicenvd nodevicepuc nodevicebxe nodevicede nodeviceem nodeviceigb nodeviceixgb nodevicele nodeviceti nodevicetxp nodevicevx nodeviceae nodeviceage nodevicealc nodeviceale nodevicebce nodevicebfe nodevicebge nodevicecas nodevicedc nodeviceet nodevicegem nodevicehme nodevicejme nodevicelge nodevicemsk nodevicenge nodevicenve nodevicepcn nodevicesf nodevicesge nodevicesis nodevicesk nodeviceste nodevicestge nodevicetl nodevicetx nodevicevge nodevicevr nodevicevte nodevicewb nodevicexl nodevicecs nodeviceed nodeviceex nodeviceep nodevicefe nodeviceie nodevicesn nodevicexe nodevicebwi nodevicebwn nodeviceipw nodeviceiwi nodeviceiwn nodevicemalo nodevicemwl nodeviceral nodevicewi nodevicewpi nodevicevirtio nodevicevirtio_pci nodevicevtnet nodevicevirtio_blk nodevicevirtio_scsi nodevicevirtio_balloon nooptions HYPERV nodevicehyperv nooptions XENHVM nodevicexenpci nodevicevmx ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On 6 Jul, Warner Losh wrote: > On Fri, Jul 6, 2018 at 6:06 PM, Don Lewis wrote: > >> On 6 Jul, Warner Losh wrote: >> > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < >> > free...@pdx.rh.cn85.dnsmgr.net> wrote: >> > >> >> > Author: hselasky >> >> > Date: Fri Jul 6 10:13:42 2018 >> >> > New Revision: 336025 >> >> > URL: https://svnweb.freebsd.org/changeset/base/336025 >> >> > >> >> > Log: >> >> > Make sure kernel modules built by default are portable between UP >> and >> >> > SMP systems by extending defined(SMP) to include >> defined(KLD_MODULE). >> >> > >> >> > This is a regression issue after r335873 . >> >> > >> >> > Discussed with: mmacy@ >> >> > Sponsored by: Mellanox Technologies >> >> >> >> Though this fixes the issue, it also means that now when >> >> anyone intentionally builds a UP kernel with modules >> >> they are getting SMP support in the modules and I am >> >> not sure they would want that. I know I don't. >> >> >> > >> > >> > On UP systems, these additional opcodes are harmless. They take a few >> extra >> > cycles (since they lock an uncontested bus) and add a couple extra memory >> > barriers (which will be NOPs). On MP systems, atomics now work by >> default. >> > Had we not defaulted like this, all modules built outside of a kernel >> build >> > env would have broken atomics. Given that (a) the overwhelming majority >> > (99% or more) is SMP and (b) the MP code merely adds a few cycles to >> what's >> > already a not-too-expensive operation, this was the right choice. >> > >> > It simply doesn't matter for systems that are relevant to the project >> > today. While one could try to optimize this a little (for example, by >> > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to >> if >> > (defined(SMP) && SMP != 0)), it's likely not going to matter enough for >> > anybody to make the effort. UP on x86 is simply not relevant enough to >> > optimize for it. Even in VMs, people run SMP kernels typically even when >> > they just allocate one CPU to the VM. >> > >> > So while we still support the UP config, and we'll let people build >> > optimized kernels for x86, we've flipped the switch from pessimized for >> SMP >> > modules to pessimized for UP modules, which seems like quite the >> reasonable >> > trade-off. >> > >> > Were it practical to do so, I'd suggest de-orbiting UP on x86. However, >> > it's a lot of work for not much benefit and we'd need to invent much >> crazy >> > to get there. >> >> I would distinguish i386 from amd64 here. SMP is pretty rare and exotic >> in the i386 world > > > I don't know I'd say that. There's been MP systems widely available since > Pentium Pro days. They aren't in laptops, but they were fairly common in > i386 land since the mid 90's, especially in server class machines. Not > cheap, but not too pricy as to be uncommon Back in the mid-90's to early 00's I was running a fairly large collection of i386-class FreeBSD servers, starting with Pentium CPUs which were mostly replaced by Pentium III's by the end. They used desktop motherboards and were all UP. They were stacked on shelves in our raised-floor computer room next to the VAX, so I consider them servers. We stopped at FreeBSD 4.x, so SMP would not have been that great anyway. The Pentium III motherboard that I purchased required the use of special Pentium III CPU chips. They were hard to find on Ebay as I recall. What is kind of funny is that the workloads I was running back in those days were mostly I/O bound. Now that CPUs have gotten so much faster and CPUs have grown so many cores, my workloads are now mostly CPU limited. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336031 - head/usr.bin/top
In message <20180706135634.gp5...@kib.kiev.ua>, Konstantin Belousov writes: > On Fri, Jul 06, 2018 at 01:22:44PM +, Sean Bruno wrote: > > Author: sbruno > > Date: Fri Jul 6 13:22:44 2018 > > New Revision: 336031 > > URL: https://svnweb.freebsd.org/changeset/base/336031 > > > > Log: > > r336028 changed next_msg to a char * from char [] of fixed size. Change > > 2nd argument of vsnprintf() to get the strlen of next_msg so that the > > appropriate size is used. > > > > Found with gcc. > > > > /usr.bin/top/display.c: In function 'new_message': > > /usr.bin/top/display.c:963:31: error: > > argument to 'sizeof' in 'vsnprintf' call is the same expression as the > > destination; did you mean to provide an explicit length? > > [-Werror=sizeof-pointer-memaccess] > >vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > > > > Reviewed by: daichi > > > > Modified: > > head/usr.bin/top/display.c > > > > Modified: head/usr.bin/top/display.c > > === > === > > --- head/usr.bin/top/display.c Fri Jul 6 12:44:48 2018(r33603 > 0) > > +++ head/usr.bin/top/display.c Fri Jul 6 13:22:44 2018(r33603 > 1) > > @@ -960,7 +960,7 @@ new_message(int type, const char *msgfmt, ...) > > va_start(args, msgfmt); > > > > /* first, format the message */ > > -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > > +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); > I highly suspect that this strlen() call returns zero, always. Yes. OTOH sizeof(next_msg) won't return much useful either, as it returns the size of the pointer. > > > > > va_end(args); > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 06, 2018 at 05:06:03PM -0700, Don Lewis wrote: > The other machine is my Pentium-M laptop, which is mostly used for light > browsing and as a VNC client when I'm on the road. Performance is > acceptable for those uses. Both machines run stripped down UP kernels to > avoid wasting RAM unnecessarily and to optimize CPU cycles on the laptop. > > [...] I've managed to commit changes that break UP builds and not known > it until I received reports of broken builds from other users. :-) That's funny: you run custom UP kernels, and yet managed to break UP builds with the breakage being unknown to you until you received reports from other users, lol. On a related note, did you measure how much (e.g. in terms of battery life) your laptop gains from using the UP kernel? Could you also share your config? I'm using Pentium-M laptop as my primary machine as well, and always eager to squeeze something more out of it. Thanks, ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336046 - in head/sys: amd64/include i386/include sys
On Fri, Jul 06, 2018 at 10:52:37PM +0300, Konstantin Belousov wrote: > On Fri, Jul 06, 2018 at 07:50:25PM +, Konstantin Belousov wrote: > > New Revision: 336046 > > URL: https://svnweb.freebsd.org/changeset/base/336046 > > > > Log: > > Revert to recommit with the proper message. > > I am sorry for the second mistake of the same sort in the day. It would be much easier if we'd allowed "svn propedit --revprop svn:log". ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336056 - head/sys/powerpc/powernv
Author: jhibbits
Date: Sat Jul 7 01:58:40 2018
New Revision: 336056
URL: https://svnweb.freebsd.org/changeset/base/336056
Log:
Let ofw_iicbus work its magic on OPAL i2c buses.
ofw_iicbus already has attachments on iichb. Rather than adding an explicit
attachment onto opal_i2c, simply change the exposed name of the OPAL i2c bus
to 'iichb'.
Modified:
head/sys/powerpc/powernv/opal_i2c.c
Modified: head/sys/powerpc/powernv/opal_i2c.c
==
--- head/sys/powerpc/powernv/opal_i2c.c Sat Jul 7 01:54:45 2018
(r336055)
+++ head/sys/powerpc/powernv/opal_i2c.c Sat Jul 7 01:58:40 2018
(r336056)
@@ -90,6 +90,7 @@ static int opal_i2c_callback(device_t, int, caddr_t);
static int opal_i2c_probe(device_t);
static int opal_i2c_transfer(device_t, struct iic_msg *, uint32_t);
static int i2c_opal_send_request(uint32_t, struct opal_i2c_request *);
+static phandle_t opal_i2c_get_node(device_t bus, device_t dev);
static device_method_t opal_i2c_methods[] = {
/* Device interface */
@@ -99,6 +100,7 @@ static device_method_t opal_i2c_methods[] = {
/* iicbus interface */
DEVMETHOD(iicbus_callback, opal_i2c_callback),
DEVMETHOD(iicbus_transfer, opal_i2c_transfer),
+ DEVMETHOD(ofw_bus_get_node, opal_i2c_get_node),
DEVMETHOD_END
};
@@ -111,7 +113,7 @@ static device_method_t opal_i2c_methods[] = {
static devclass_t opal_i2c_devclass;
static driver_t opal_i2c_driver = {
- "i2c",
+ "iichb",
opal_i2c_methods,
sizeof(struct opal_i2c_softc),
};
@@ -244,6 +246,14 @@ opal_i2c_callback(device_t dev, int index, caddr_t dat
}
return (error);
+}
+
+static phandle_t
+opal_i2c_get_node(device_t bus, device_t dev)
+{
+
+ /* Share controller node with iibus device. */
+ return (ofw_bus_get_node(bus));
}
DRIVER_MODULE(opal_i2c, opal_i2cm, opal_i2c_driver, opal_i2c_devclass, NULL,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336055 - head/sys/vm
Author: jeff
Date: Sat Jul 7 01:54:45 2018
New Revision: 336055
URL: https://svnweb.freebsd.org/changeset/base/336055
Log:
Use the ticks since the last update to reduce hysteresis in the partpopq and
contention on the vm_reserv_domain lock.
This gives a roughly 8x speedup on will-it-scale fault1 on a 16 core machine.
Reviewed by: alc, kib, markj
Modified:
head/sys/vm/vm_reserv.c
Modified: head/sys/vm/vm_reserv.c
==
--- head/sys/vm/vm_reserv.c Sat Jul 7 00:41:04 2018(r336054)
+++ head/sys/vm/vm_reserv.c Sat Jul 7 01:54:45 2018(r336055)
@@ -116,6 +116,12 @@ typedefu_long popmap_t;
#defineNPOPMAP howmany(VM_LEVEL_0_NPAGES, NBPOPMAP)
/*
+ * Number of elapsed ticks before we update the LRU queue position. Used
+ * to reduce contention and churn on the list.
+ */
+#definePARTPOPSLOP 1
+
+/*
* Clear a bit in the population map.
*/
static __inline void
@@ -183,6 +189,7 @@ struct vm_reserv {
vm_page_t pages; /* (c) first page */
uint16_tdomain; /* (c) NUMA domain. */
uint16_tpopcnt; /* (r) # of pages in use */
+ int lasttick; /* (r) last pop update tick. */
charinpartpopq; /* (d) */
popmap_tpopmap[NPOPMAP];/* (r) bit vector, used pages */
};
@@ -394,6 +401,7 @@ vm_reserv_insert(vm_reserv_t rv, vm_object_t object, v
vm_reserv_object_lock(object);
rv->pindex = pindex;
rv->object = object;
+ rv->lasttick = ticks;
LIST_INSERT_HEAD(>rvq, rv, objq);
vm_reserv_object_unlock(object);
}
@@ -430,16 +438,20 @@ vm_reserv_depopulate(vm_reserv_t rv, int index)
}
popmap_clear(rv->popmap, index);
rv->popcnt--;
- vm_reserv_domain_lock(rv->domain);
- if (rv->inpartpopq) {
- TAILQ_REMOVE(_rvq_partpop[rv->domain], rv, partpopq);
- rv->inpartpopq = FALSE;
+ if ((unsigned)(ticks - rv->lasttick) >= PARTPOPSLOP ||
+ rv->popcnt == 0) {
+ vm_reserv_domain_lock(rv->domain);
+ if (rv->inpartpopq) {
+ TAILQ_REMOVE(_rvq_partpop[rv->domain], rv, partpopq);
+ rv->inpartpopq = FALSE;
+ }
+ if (rv->popcnt != 0) {
+ rv->inpartpopq = TRUE;
+ TAILQ_INSERT_TAIL(_rvq_partpop[rv->domain], rv,
partpopq);
+ }
+ vm_reserv_domain_unlock(rv->domain);
+ rv->lasttick = ticks;
}
- if (rv->popcnt != 0) {
- rv->inpartpopq = TRUE;
- TAILQ_INSERT_TAIL(_rvq_partpop[rv->domain], rv, partpopq);
- }
- vm_reserv_domain_unlock(rv->domain);
vmd = VM_DOMAIN(rv->domain);
if (rv->popcnt == 0) {
vm_reserv_remove(rv);
@@ -536,6 +548,10 @@ vm_reserv_populate(vm_reserv_t rv, int index)
rv, rv->domain));
popmap_set(rv->popmap, index);
rv->popcnt++;
+ if ((unsigned)(ticks - rv->lasttick) < PARTPOPSLOP &&
+ rv->inpartpopq && rv->popcnt != VM_LEVEL_0_NPAGES)
+ return;
+ rv->lasttick = ticks;
vm_reserv_domain_lock(rv->domain);
if (rv->inpartpopq) {
TAILQ_REMOVE(_rvq_partpop[rv->domain], rv, partpopq);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 6, 2018 at 6:06 PM, Don Lewis wrote: > On 6 Jul, Warner Losh wrote: > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> > Author: hselasky > >> > Date: Fri Jul 6 10:13:42 2018 > >> > New Revision: 336025 > >> > URL: https://svnweb.freebsd.org/changeset/base/336025 > >> > > >> > Log: > >> > Make sure kernel modules built by default are portable between UP > and > >> > SMP systems by extending defined(SMP) to include > defined(KLD_MODULE). > >> > > >> > This is a regression issue after r335873 . > >> > > >> > Discussed with: mmacy@ > >> > Sponsored by: Mellanox Technologies > >> > >> Though this fixes the issue, it also means that now when > >> anyone intentionally builds a UP kernel with modules > >> they are getting SMP support in the modules and I am > >> not sure they would want that. I know I don't. > >> > > > > > > On UP systems, these additional opcodes are harmless. They take a few > extra > > cycles (since they lock an uncontested bus) and add a couple extra memory > > barriers (which will be NOPs). On MP systems, atomics now work by > default. > > Had we not defaulted like this, all modules built outside of a kernel > build > > env would have broken atomics. Given that (a) the overwhelming majority > > (99% or more) is SMP and (b) the MP code merely adds a few cycles to > what's > > already a not-too-expensive operation, this was the right choice. > > > > It simply doesn't matter for systems that are relevant to the project > > today. While one could try to optimize this a little (for example, by > > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to > if > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough for > > anybody to make the effort. UP on x86 is simply not relevant enough to > > optimize for it. Even in VMs, people run SMP kernels typically even when > > they just allocate one CPU to the VM. > > > > So while we still support the UP config, and we'll let people build > > optimized kernels for x86, we've flipped the switch from pessimized for > SMP > > modules to pessimized for UP modules, which seems like quite the > reasonable > > trade-off. > > > > Were it practical to do so, I'd suggest de-orbiting UP on x86. However, > > it's a lot of work for not much benefit and we'd need to invent much > crazy > > to get there. > > I would distinguish i386 from amd64 here. SMP is pretty rare and exotic > in the i386 world I don't know I'd say that. There's been MP systems widely available since Pentium Pro days. They aren't in laptops, but they were fairly common in i386 land since the mid 90's, especially in server class machines. Not cheap, but not too pricy as to be uncommon > I do have one dual socket Pentium 3 machine here and > even though I bought the parts for it used on eBay, it was still pretty > pricey. That purchase was kind of a waste since it was shortly before > the Athlon 64 X2 CPUs were released. > > I still have two viable 32-bit x86 machines here that get frequent > usage. One runs 24x7 and has a Via C3 CPU. I started looking at > migrating off this hardware. To get lower power consumption as well as > ECC RAM I'd probably have to go with one of the Supermicro Atom boards. > Those are pretty expensive, so I'd probably end up spending about half > as much as what it cost to put together my fully-loaded Ryzen machine > last summer. At that price, the payback time from the power savings is > really long. This machine is mostly idle, so I really don't need more > CPU power or RAM. The other machine is my Pentium-M laptop, which is > mostly used for light browsing and as a vnc client when I'm on the road. > Performance is acceptable for those uses. Both machines run stripped > down UP kernels to avoid wasting RAM unnecessarily and to optimize CPU > cycles on the laptop. > > A good reason for continuing UP support on x86 is to make it easy to > test UP builds in the MI parts of the kernel so that we don't break > things for the embedded architectures. Unfortunately "make universe" > currently doesn't have any UP kernels, so I've managed to commit changes > that break UP builds and not known it until I received reports of broken > builds from other users > UP kernels have not changed. The setups that have UP kernels generally need custom ones anyway, since there's so many devices that aren't used. Those setups aren't affected by this change. You raise an interesting point, though: it hasn't been important enough to the project to include a UP kernel in CI testing we've done for years and years... Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336054 - head/sys/dev/hyperv/vmbus
Author: dexuan Date: Sat Jul 7 00:41:04 2018 New Revision: 336054 URL: https://svnweb.freebsd.org/changeset/base/336054 Log: hyperv: Fix boot-up after malloc() returns memory of NX by default now FreeBSD VM can't boot up on Hyper-V after the recent malloc change in r335068: Make UMA and malloc(9) return non-executable memory in most cases. The hypercall page here must be executable. Fix the boot-up issue by adding M_EXEC. PR: 229167 Sponsored by: Microsoft Modified: head/sys/dev/hyperv/vmbus/hyperv.c Modified: head/sys/dev/hyperv/vmbus/hyperv.c == --- head/sys/dev/hyperv/vmbus/hyperv.c Fri Jul 6 23:49:17 2018 (r336053) +++ head/sys/dev/hyperv/vmbus/hyperv.c Sat Jul 7 00:41:04 2018 (r336054) @@ -284,7 +284,7 @@ hypercall_create(void *arg __unused) * - Assume kmem_malloc() returns properly aligned memory. */ hypercall_context.hc_addr = (void *)kmem_malloc(kernel_arena, PAGE_SIZE, - M_WAITOK); + M_EXEC | M_WAITOK); hypercall_context.hc_paddr = vtophys(hypercall_context.hc_addr); /* Get the 'reserved' bits, which requires preservation. */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On 6 Jul, Warner Losh wrote: > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > Author: hselasky >> > Date: Fri Jul 6 10:13:42 2018 >> > New Revision: 336025 >> > URL: https://svnweb.freebsd.org/changeset/base/336025 >> > >> > Log: >> > Make sure kernel modules built by default are portable between UP and >> > SMP systems by extending defined(SMP) to include defined(KLD_MODULE). >> > >> > This is a regression issue after r335873 . >> > >> > Discussed with: mmacy@ >> > Sponsored by: Mellanox Technologies >> >> Though this fixes the issue, it also means that now when >> anyone intentionally builds a UP kernel with modules >> they are getting SMP support in the modules and I am >> not sure they would want that. I know I don't. >> > > > On UP systems, these additional opcodes are harmless. They take a few extra > cycles (since they lock an uncontested bus) and add a couple extra memory > barriers (which will be NOPs). On MP systems, atomics now work by default. > Had we not defaulted like this, all modules built outside of a kernel build > env would have broken atomics. Given that (a) the overwhelming majority > (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's > already a not-too-expensive operation, this was the right choice. > > It simply doesn't matter for systems that are relevant to the project > today. While one could try to optimize this a little (for example, by > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if > (defined(SMP) && SMP != 0)), it's likely not going to matter enough for > anybody to make the effort. UP on x86 is simply not relevant enough to > optimize for it. Even in VMs, people run SMP kernels typically even when > they just allocate one CPU to the VM. > > So while we still support the UP config, and we'll let people build > optimized kernels for x86, we've flipped the switch from pessimized for SMP > modules to pessimized for UP modules, which seems like quite the reasonable > trade-off. > > Were it practical to do so, I'd suggest de-orbiting UP on x86. However, > it's a lot of work for not much benefit and we'd need to invent much crazy > to get there. I would distinguish i386 from amd64 here. SMP is pretty rare and exotic in the i386 world. I do have one dual socket Pentium 3 machine here and even though I bought the parts for it used on eBay, it was still pretty pricey. That purchase was kind of a waste since it was shortly before the Athlon 64 X2 CPUs were released. I still have two viable 32-bit x86 machines here that get frequent usage. One runs 24x7 and has a Via C3 CPU. I started looking at migrating off this hardware. To get lower power consumption as well as ECC RAM I'd probably have to go with one of the Supermicro Atom boards. Those are pretty expensive, so I'd probably end up spending about half as much as what it cost to put together my fully-loaded Ryzen machine last summer. At that price, the payback time from the power savings is really long. This machine is mostly idle, so I really don't need more CPU power or RAM. The other machine is my Pentium-M laptop, which is mostly used for light browsing and as a vnc client when I'm on the road. Performance is acceptable for those uses. Both machines run stripped down UP kernels to avoid wasting RAM unnecessarily and to optimize CPU cycles on the laptop. A good reason for continuing UP support on x86 is to make it easy to test UP builds in the MI parts of the kernel so that we don't break things for the embedded architectures. Unfortunately "make universe" currently doesn't have any UP kernels, so I've managed to commit changes that break UP builds and not known it until I received reports of broken builds from other users. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336028 - head/usr.bin/top
Daichi GOTO wrote in <201807061207.w66c76cr043...@repo.freebsd.org>: da> Author: daichi da> Date: Fri Jul 6 12:07:06 2018 da> New Revision: 336028 da> URL: https://svnweb.freebsd.org/changeset/base/336028 da> da> Log: da> Changed to eliminate the upper limit of command length displayed da> by "-a" and expand to match terminal width da> da> Reviewed by: eadler da> Approved by: gnn (mentor) da> Differential Revision:https://reviews.freebsd.org/D16083 da> da> Modified: da> head/usr.bin/top/display.c da> head/usr.bin/top/machine.c da> head/usr.bin/top/screen.c da> head/usr.bin/top/top.h This change breaks displaying a prompt and messages in the interactive mode by new_message() when typing "o" or "p", for example. While r336031 fixed a warning in GCC, it does not fix the problem itself. Please fix it. I also think restructure of the buffer management is required first if we want to eliminate the column width limitation. Using sbuf(9) consistently may be better than incomplete conversion from static arrays to malloc(). -- Hiroki pgpwYfF61gB5W.pgp Description: PGP signature
svn commit: r336053 - in head: sys/arm/include sys/arm64/include tests/sys/kern
Author: jhb
Date: Fri Jul 6 23:49:17 2018
New Revision: 336053
URL: https://svnweb.freebsd.org/changeset/base/336053
Log:
Export a breakpoint() function to userland for arm and arm64.
Enable ptrace() tests using breakpoint() on these architectures.
Reviewed by: andrew
Differential Revision:https://reviews.freebsd.org/D15191
Modified:
head/sys/arm/include/cpufunc.h
head/sys/arm64/include/cpufunc.h
head/tests/sys/kern/ptrace_test.c
Modified: head/sys/arm/include/cpufunc.h
==
--- head/sys/arm/include/cpufunc.h Fri Jul 6 22:07:26 2018
(r336052)
+++ head/sys/arm/include/cpufunc.h Fri Jul 6 23:49:17 2018
(r336053)
@@ -54,7 +54,7 @@
static __inline void
breakpoint(void)
{
- __asm(".word 0xe7ff");
+ __asm("udf0x");
}
struct cpu_functions {
@@ -494,6 +494,19 @@ extern int arm_dcache_align_mask;
extern u_int arm_cache_level;
extern u_int arm_cache_loc;
extern u_int arm_cache_type[14];
+
+#else /* !_KERNEL */
+
+static __inline void
+breakpoint(void)
+{
+
+ /*
+* This matches the instruction used by GDB for software
+* breakpoints.
+*/
+ __asm("udf0xfdee");
+}
#endif /* _KERNEL */
#endif /* _MACHINE_CPUFUNC_H_ */
Modified: head/sys/arm64/include/cpufunc.h
==
--- head/sys/arm64/include/cpufunc.hFri Jul 6 22:07:26 2018
(r336052)
+++ head/sys/arm64/include/cpufunc.hFri Jul 6 23:49:17 2018
(r336053)
@@ -29,18 +29,18 @@
#ifndef _MACHINE_CPUFUNC_H_
#define_MACHINE_CPUFUNC_H_
-#ifdef _KERNEL
-
-#include
-
-void pan_enable(void);
-
static __inline void
breakpoint(void)
{
__asm("brk #0");
}
+
+#ifdef _KERNEL
+
+#include
+
+void pan_enable(void);
static __inline register_t
dbg_disable(void)
Modified: head/tests/sys/kern/ptrace_test.c
==
--- head/tests/sys/kern/ptrace_test.c Fri Jul 6 22:07:26 2018
(r336052)
+++ head/tests/sys/kern/ptrace_test.c Fri Jul 6 23:49:17 2018
(r336053)
@@ -54,8 +54,9 @@ __FBSDID("$FreeBSD$");
/*
* Architectures with a user-visible breakpoint().
*/
-#if defined(__amd64__) || defined(__i386__) || defined(__mips__) ||\
-defined(__riscv) || defined(__sparc64__)
+#if defined(__aarch64__) || defined(__amd64__) || defined(__arm__) || \
+defined(__i386__) || defined(__mips__) || defined(__riscv) || \
+defined(__sparc64__)
#defineHAVE_BREAKPOINT
#endif
@@ -63,8 +64,12 @@ __FBSDID("$FreeBSD$");
* Adjust PC to skip over a breakpoint when stopped for a breakpoint trap.
*/
#ifdef HAVE_BREAKPOINT
-#if defined(__amd64__) || defined(__i386__)
+#if defined(__aarch64__)
+#defineSKIP_BREAK(reg) ((reg)->elr += 4)
+#elif defined(__amd64__) || defined(__i386__)
#defineSKIP_BREAK(reg)
+#elif defined(__arm__)
+#defineSKIP_BREAK(reg) ((reg)->r_pc += 4)
#elif defined(__mips__)
#defineSKIP_BREAK(reg) ((reg)->r_regs[PC] += 4)
#elif defined(__riscv)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, 6 Jul 2018, Rodney W. Grimes wrote: On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: Author: hselasky Date: Fri Jul 6 10:13:42 2018 New Revision: 336025 URL: https://svnweb.freebsd.org/changeset/base/336025 Log: Make sure kernel modules built by default are portable between UP and SMP systems by extending defined(SMP) to include defined(KLD_MODULE). This is a regression issue after r335873 . Discussed with: mmacy@ Sponsored by: Mellanox Technologies Though this fixes the issue, it also means that now when anyone intentionally builds a UP kernel with modules they are getting SMP support in the modules and I am not sure they would want that. I know I don't. On UP systems, these additional opcodes are harmless. They take a few extra cycles (since they lock an uncontested bus) and add a couple extra memory barriers (which will be NOPs). On MP systems, atomics now work by default. Had we not defaulted like this, all modules built outside of a kernel build env would have broken atomics. Given that (a) the overwhelming majority (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's already a not-too-expensive operation, this was the right choice. It simply doesn't matter for systems that are relevant to the project today. While one could try to optimize this a little (for example, by having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if (defined(SMP) && SMP != 0)), it's likely not going to matter enough for anybody to make the effort. UP on x86 is simply not relevant enough to optimize for it. Even in VMs, people run SMP kernels typically even when they just allocate one CPU to the VM. So while we still support the UP config, and we'll let people build optimized kernels for x86, we've flipped the switch from pessimized for SMP modules to pessimized for UP modules, which seems like quite the reasonable trade-off. Were it practical to do so, I'd suggest de-orbiting UP on x86. However, it's a lot of work for not much benefit and we'd need to invent much crazy to get there. Trivial to fix this with +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || !defined(KLD_UP_MODULES) Nope. Not so trivial. Who defines KLD_UP_MODULES? Call it SMP_KLD_MODULES, and it gets defined the same place SMP does. Not so simple. SMP is defined in the config file, and winds up in one of No problem, that is where I would be defining this anyway, or in the latest case removing it and SMP for my UP kernel build. the option files. It will be absent for stand alone builds, I am ok with that. And it would be reasonable to default to SMP. though. These change tweak the default yo be inlined and to include the sequence that works everywhere. And really, it's absolutely not worth it unless someone shows up with numbers to show the old 'function call to optimal routine' is actually faster than the new 'inline to slightly unoptimal code'. Since I think the function call overhead is larger than the pessmizations, I'm not sure what the fuss is about. I have no issues with the SMP converting from function calls to inline locks, I just want to retain the exact same code I had before any of these changes, and that was A UP built system without any SMP locking. Is it too much to ask to keep what already worked? This doesn't enable or disable locks in the muted sense. It just changes the atomic ops for the kernel from a function call to an inlined function. The inlining is more efficient than the call, even with the overhead added by always inlining the same stuff. It still is faster than before. And userland has done this forever... So I honestly think even UP builds are better off, even if it's not hyper optimized for UP. The lock instruction prefix is minimal overhead (a cycle I think). I do not believe, and Bruce seems to have evidence, that LOCK is not a one cycle cost. And in my head I know that it can not be that simple as it causes lots of very special things to happen in the pipeline to ensure you are locked. It is definitely not one cycle. It is a couple dozen depending on the machine. You can benchmark yourself with the attached patch. Here's two atomics in a loop with and without lock on a Zen: desktop# ./nonatomic 0 8838: 8 ns desktop# ./atomic 0 32887: 32 ns This is at ~3ghz so three instructions per-ns. Cut this in half for per-atomic cost. 12ns of overhead or 36 cycles. One of them is a fetchadd so there is extra cost associated with that. This is also worst case because the machine can't execute anything other than the atomics. If there were other instructions that didn't operate on overlapping memory addresses they
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, 6 Jul 2018, Rodney W. Grimes wrote: On Friday, July 6, 2018, Rodney W. Grimes wrote: Author: hselasky Date: Fri Jul 6 10:13:42 2018 New Revision: 336025 URL: https://svnweb.freebsd.org/changeset/base/336025 Log: Make sure kernel modules built by default are portable between UP and SMP systems by extending defined(SMP) to include defined(KLD_MODULE). This is a regression issue after r335873 . Discussed with: mmacy@ Sponsored by: Mellanox Technologies Though this fixes the issue, it also means that now when anyone intentionally builds a UP kernel with modules they are getting SMP support in the modules and I am not sure they would want that. I know I don't. On linux case the lock instructions are runtime patchable. They have so called altinstruction facility, which able to detect specific conditions - in this case up vs smp - and in up case the locks are replaced with simple nops or one multi word nop when the instruction longer than 1 byte. Thank you for this information, which lends credibilty to the fact that these LOCK instructions may not be as cheap as some think they are, as why would the Linux people bother with run time patching code if infact it was that cheap. This code to patch in linux dates from a time when lock was incredibly expensive and SMP was rare. On x86 of the era lock would actually assert a bus lock on the north bridge. Today lock prefix without contention is not particularly expensive, about the same as a divide, as long as the line is in cache. If it is not in cache, the memory access is an order of magnitude more expensive than the atomic. If it is contended then you have different problems. My feeling is that these days more people overestimate the cost of atomics than under estimate. It's really the _sharing_ that is expensive. Thanks, Jeff I would not want to take that approach though. ... commit diff text deleted ... -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336052 - in head/sys/modules: uchcom ucycom
Author: ian
Date: Fri Jul 6 22:07:26 2018
New Revision: 336052
URL: https://svnweb.freebsd.org/changeset/base/336052
Log:
Set .PATH to dev/usb/serial so that these modules compile again.
Modified:
head/sys/modules/uchcom/Makefile
head/sys/modules/ucycom/Makefile
Modified: head/sys/modules/uchcom/Makefile
==
--- head/sys/modules/uchcom/MakefileFri Jul 6 22:01:00 2018
(r336051)
+++ head/sys/modules/uchcom/MakefileFri Jul 6 22:07:26 2018
(r336052)
@@ -1,7 +1,7 @@
# $FreeBSD$
S= ${SRCTOP}/sys
-.PATH: $S/dev/usb
+.PATH: $S/dev/usb/serial
KMOD= uchcom
SRCS= uchcom.c opt_usb.h device_if.h bus_if.h usbdevs.h
Modified: head/sys/modules/ucycom/Makefile
==
--- head/sys/modules/ucycom/MakefileFri Jul 6 22:01:00 2018
(r336051)
+++ head/sys/modules/ucycom/MakefileFri Jul 6 22:07:26 2018
(r336052)
@@ -1,7 +1,7 @@
# $FreeBSD$
S= ${SRCTOP}/sys
-.PATH: $S/dev/usb
+.PATH: $S/dev/usb/serial
KMOD= ucycom
SRCS= ucycom.c opt_usb.h device_if.h bus_if.h usbdevs.h
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336051 - head/sys/dev/ichiic
Author: gonzo
Date: Fri Jul 6 22:01:00 2018
New Revision: 336051
URL: https://svnweb.freebsd.org/changeset/base/336051
Log:
ig4(4): Fix Apollo lake entries platform identifier
Identify Apollo Lake controllers as IG4_APL and not as a IG4_SKYLAKE
Reported by: rpokala@
Modified:
head/sys/dev/ichiic/ig4_pci.c
Modified: head/sys/dev/ichiic/ig4_pci.c
==
--- head/sys/dev/ichiic/ig4_pci.c Fri Jul 6 21:22:50 2018
(r336050)
+++ head/sys/dev/ichiic/ig4_pci.c Fri Jul 6 22:01:00 2018
(r336051)
@@ -110,14 +110,14 @@ static struct ig4iic_pci_device ig4iic_pci_devices[] =
{ PCI_CHIP_SKYLAKE_I2C_3, "Intel Sunrise Point-LP I2C Controller-3",
IG4_SKYLAKE},
{ PCI_CHIP_SKYLAKE_I2C_4, "Intel Sunrise Point-LP I2C Controller-4",
IG4_SKYLAKE},
{ PCI_CHIP_SKYLAKE_I2C_5, "Intel Sunrise Point-LP I2C Controller-5",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_0, "Intel Apollo Lake I2C Controller-0",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_1, "Intel Apollo Lake I2C Controller-1",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_2, "Intel Apollo Lake I2C Controller-2",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_3, "Intel Apollo Lake I2C Controller-3",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_4, "Intel Apollo Lake I2C Controller-4",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_5, "Intel Apollo Lake I2C Controller-5",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_6, "Intel Apollo Lake I2C Controller-6",
IG4_SKYLAKE},
- { PCI_CHIP_APL_I2C_7, "Intel Apollo Lake I2C Controller-7",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_0, "Intel Apollo Lake I2C Controller-0", IG4_APL},
+ { PCI_CHIP_APL_I2C_1, "Intel Apollo Lake I2C Controller-1", IG4_APL},
+ { PCI_CHIP_APL_I2C_2, "Intel Apollo Lake I2C Controller-2", IG4_APL},
+ { PCI_CHIP_APL_I2C_3, "Intel Apollo Lake I2C Controller-3", IG4_APL},
+ { PCI_CHIP_APL_I2C_4, "Intel Apollo Lake I2C Controller-4", IG4_APL},
+ { PCI_CHIP_APL_I2C_5, "Intel Apollo Lake I2C Controller-5", IG4_APL},
+ { PCI_CHIP_APL_I2C_6, "Intel Apollo Lake I2C Controller-6", IG4_APL},
+ { PCI_CHIP_APL_I2C_7, "Intel Apollo Lake I2C Controller-7", IG4_APL},
{ 0, NULL, 0 },
};
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> On Friday, July 6, 2018, Rodney W. Grimes > wrote: > > > > Author: hselasky > > > Date: Fri Jul 6 10:13:42 2018 > > > New Revision: 336025 > > > URL: https://svnweb.freebsd.org/changeset/base/336025 > > > > > > Log: > > > Make sure kernel modules built by default are portable between UP and > > > SMP systems by extending defined(SMP) to include defined(KLD_MODULE). > > > > > > This is a regression issue after r335873 . > > > > > > Discussed with: mmacy@ > > > Sponsored by: Mellanox Technologies > > > > Though this fixes the issue, it also means that now when > > anyone intentionally builds a UP kernel with modules > > they are getting SMP support in the modules and I am > > not sure they would want that. I know I don't. > > > > > On linux case the lock instructions are runtime patchable. They have so > called altinstruction facility, which able to detect specific conditions - > in this case up vs smp - and in up case the locks are replaced with simple > nops or one multi word nop when the instruction longer than 1 byte. Thank you for this information, which lends credibilty to the fact that these LOCK instructions may not be as cheap as some think they are, as why would the Linux people bother with run time patching code if infact it was that cheap. I would not want to take that approach though. ... commit diff text deleted ... -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336020 - in head/sys: amd64/include arm/include arm64/include i386/include kern mips/include powerpc/include riscv/include sparc64/include sys vm x86/acpica
On 7/5/18 7:06 PM, Matt Macy wrote: > Author: mmacy > Date: Fri Jul 6 02:06:03 2018 > New Revision: 336020 > URL: https://svnweb.freebsd.org/changeset/base/336020 > > Log: > Back pcpu zone with domain correct pages > > - Change pcpu zone consumers to use a stride size of PAGE_SIZE. > (defined as UMA_PCPU_ALLOC_SIZE to make future identification easier) > > - Allocate page from the correct domain for a given cpu. > > - Don't initialize pc_domain to non-zero value if NUMA is not defined > There are some misconceptions surrounding this field. It is the > _VM_ NUMA domain and should only ever correspond to valid domain > values as understood by the VM. > > The former slab size of sizeof(struct pcpu) was somewhat arbitrary. > The new value is PAGE_SIZE because that's the smallest granularity > which the VM can allocate a slab for a given domain. If you have > fewer than PAGE_SIZE/8 counters on your system there will be some > memory wasted, but this is obviously something where you want the > cache line to be coming from the correct domain. > > Reviewed by: jeff > Sponsored by: Limelight Networks > Differential Revision: https://reviews.freebsd.org/D15933 So one thing about this change that confused me abit is why any of srat.c is being run at all in a non-NUMA kernel. When we reworked the NUMA options in HEAD to merge DEVICE_NUMA and VM_NUMA_ALLOC or whatever it was called into a single NUMA, my impression is that srat.c should be 'optional numa' in sys/conf/files.*. Is it just oversight that that wasn't done earlier, and should we in fact do that now? -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336050 - head/sys/dev/ichiic
Author: gonzo
Date: Fri Jul 6 21:22:50 2018
New Revision: 336050
URL: https://svnweb.freebsd.org/changeset/base/336050
Log:
ig4(4): add support for Apollo Lake I2C controllers
Add PCI ids for I2C controllers on Apollo Lake platform. Also convert
switch/case probe logic into a table.
Reviewed by: avg
Differential Revision:https://reviews.freebsd.org/D16120
Modified:
head/sys/dev/ichiic/ig4_pci.c
head/sys/dev/ichiic/ig4_var.h
Modified: head/sys/dev/ichiic/ig4_pci.c
==
--- head/sys/dev/ichiic/ig4_pci.c Fri Jul 6 21:01:52 2018
(r336049)
+++ head/sys/dev/ichiic/ig4_pci.c Fri Jul 6 21:22:50 2018
(r336050)
@@ -80,73 +80,63 @@ static int ig4iic_pci_detach(device_t dev);
#define PCI_CHIP_SKYLAKE_I2C_3 0x9d638086
#define PCI_CHIP_SKYLAKE_I2C_4 0x9d648086
#define PCI_CHIP_SKYLAKE_I2C_5 0x9d658086
+#define PCI_CHIP_APL_I2C_0 0x5aac8086
+#define PCI_CHIP_APL_I2C_1 0x5aae8086
+#define PCI_CHIP_APL_I2C_2 0x5ab08086
+#define PCI_CHIP_APL_I2C_3 0x5ab28086
+#define PCI_CHIP_APL_I2C_4 0x5ab48086
+#define PCI_CHIP_APL_I2C_5 0x5ab68086
+#define PCI_CHIP_APL_I2C_6 0x5ab88086
+#define PCI_CHIP_APL_I2C_7 0x5aba8086
+struct ig4iic_pci_device {
+ uint32_tdevid;
+ const char *desc;
+ enum ig4_vers version;
+};
+
+static struct ig4iic_pci_device ig4iic_pci_devices[] = {
+ { PCI_CHIP_LYNXPT_LP_I2C_1, "Intel Lynx Point-LP I2C Controller-1",
IG4_HASWELL},
+ { PCI_CHIP_LYNXPT_LP_I2C_2, "Intel Lynx Point-LP I2C Controller-2",
IG4_HASWELL},
+ { PCI_CHIP_BRASWELL_I2C_1, "Intel Braswell Serial I/O I2C Port 1",
IG4_ATOM},
+ { PCI_CHIP_BRASWELL_I2C_2, "Intel Braswell Serial I/O I2C Port 2",
IG4_ATOM},
+ { PCI_CHIP_BRASWELL_I2C_3, "Intel Braswell Serial I/O I2C Port 3",
IG4_ATOM},
+ { PCI_CHIP_BRASWELL_I2C_5, "Intel Braswell Serial I/O I2C Port 5",
IG4_ATOM},
+ { PCI_CHIP_BRASWELL_I2C_6, "Intel Braswell Serial I/O I2C Port 6",
IG4_ATOM},
+ { PCI_CHIP_BRASWELL_I2C_7, "Intel Braswell Serial I/O I2C Port 7",
IG4_ATOM},
+ { PCI_CHIP_SKYLAKE_I2C_0, "Intel Sunrise Point-LP I2C Controller-0",
IG4_SKYLAKE},
+ { PCI_CHIP_SKYLAKE_I2C_1, "Intel Sunrise Point-LP I2C Controller-1",
IG4_SKYLAKE},
+ { PCI_CHIP_SKYLAKE_I2C_2, "Intel Sunrise Point-LP I2C Controller-2",
IG4_SKYLAKE},
+ { PCI_CHIP_SKYLAKE_I2C_3, "Intel Sunrise Point-LP I2C Controller-3",
IG4_SKYLAKE},
+ { PCI_CHIP_SKYLAKE_I2C_4, "Intel Sunrise Point-LP I2C Controller-4",
IG4_SKYLAKE},
+ { PCI_CHIP_SKYLAKE_I2C_5, "Intel Sunrise Point-LP I2C Controller-5",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_0, "Intel Apollo Lake I2C Controller-0",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_1, "Intel Apollo Lake I2C Controller-1",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_2, "Intel Apollo Lake I2C Controller-2",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_3, "Intel Apollo Lake I2C Controller-3",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_4, "Intel Apollo Lake I2C Controller-4",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_5, "Intel Apollo Lake I2C Controller-5",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_6, "Intel Apollo Lake I2C Controller-6",
IG4_SKYLAKE},
+ { PCI_CHIP_APL_I2C_7, "Intel Apollo Lake I2C Controller-7",
IG4_SKYLAKE},
+ { 0, NULL, 0 },
+};
+
static int
ig4iic_pci_probe(device_t dev)
{
ig4iic_softc_t *sc = device_get_softc(dev);
+ uint32_t devid;
+ int i;
- switch(pci_get_devid(dev)) {
- case PCI_CHIP_LYNXPT_LP_I2C_1:
- device_set_desc(dev, "Intel Lynx Point-LP I2C Controller-1");
- sc->version = IG4_HASWELL;
- break;
- case PCI_CHIP_LYNXPT_LP_I2C_2:
- device_set_desc(dev, "Intel Lynx Point-LP I2C Controller-2");
- sc->version = IG4_HASWELL;
- break;
- case PCI_CHIP_BRASWELL_I2C_1:
- device_set_desc(dev, "Intel Braswell Serial I/O I2C Port 1");
- sc->version = IG4_ATOM;
- break;
- case PCI_CHIP_BRASWELL_I2C_2:
- device_set_desc(dev, "Intel Braswell Serial I/O I2C Port 2");
- sc->version = IG4_ATOM;
- break;
- case PCI_CHIP_BRASWELL_I2C_3:
- device_set_desc(dev, "Intel Braswell Serial I/O I2C Port 3");
- sc->version = IG4_ATOM;
- break;
- case PCI_CHIP_BRASWELL_I2C_5:
- device_set_desc(dev, "Intel Braswell Serial I/O I2C Port 5");
- sc->version = IG4_ATOM;
- break;
- case PCI_CHIP_BRASWELL_I2C_6:
- device_set_desc(dev, "Intel Braswell Serial I/O I2C Port 6");
- sc->version = IG4_ATOM;
- break;
- case PCI_CHIP_BRASWELL_I2C_7:
-
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Friday, July 6, 2018, Rodney W. Grimes
wrote:
> > Author: hselasky
> > Date: Fri Jul 6 10:13:42 2018
> > New Revision: 336025
> > URL: https://svnweb.freebsd.org/changeset/base/336025
> >
> > Log:
> > Make sure kernel modules built by default are portable between UP and
> > SMP systems by extending defined(SMP) to include defined(KLD_MODULE).
> >
> > This is a regression issue after r335873 .
> >
> > Discussed with: mmacy@
> > Sponsored by: Mellanox Technologies
>
> Though this fixes the issue, it also means that now when
> anyone intentionally builds a UP kernel with modules
> they are getting SMP support in the modules and I am
> not sure they would want that. I know I don't.
>
>
On linux case the lock instructions are runtime patchable. They have so
called altinstruction facility, which able to detect specific conditions -
in this case up vs smp - and in up case the locks are replaced with simple
nops or one multi word nop when the instruction longer than 1 byte.
> > Modified:
> > head/sys/amd64/include/atomic.h
> > head/sys/i386/include/atomic.h
> >
> > Modified: head/sys/amd64/include/atomic.h
> >
> ==
> > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> (r336024)
> > +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> (r336025)
> > @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(volatile
> u_##TYPE *p, u_
> > * For userland, always use lock prefixes so that the binaries will run
> > * on both SMP and !SMP systems.
> > */
> > -#if defined(SMP) || !defined(_KERNEL)
> > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > #define MPLOCKED"lock ; "
> > #else
> > #define MPLOCKED
> > @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p, u_int
> v)
> > */
> > #define OFFSETOF_MONITORBUF 0x100
> >
> > -#if defined(SMP)
> > +#if defined(SMP) || defined(KLD_MODULE)
> > static __inline void
> > __storeload_barrier(void)
> > {
> >
> > Modified: head/sys/i386/include/atomic.h
> >
> ==
> > --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> (r336024)
> > +++ head/sys/i386/include/atomic.hFri Jul 6 10:13:42 2018
> (r336025)
> > @@ -143,7 +143,7 @@ void atomic_subtract_64(volatile
> uint64_t *, uint64_t
> > * For userland, always use lock prefixes so that the binaries will run
> > * on both SMP and !SMP systems.
> > */
> > -#if defined(SMP) || !defined(_KERNEL)
> > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > #define MPLOCKED"lock ; "
> > #else
> > #define MPLOCKED
> > @@ -302,7 +302,7 @@ atomic_testandclear_int(volatile u_int *p, u_int v)
> > */
> >
> > #if defined(_KERNEL)
> > -#if defined(SMP)
> > +#if defined(SMP) || defined(KLD_MODULE)
> > #define __storeload_barrier() __mbk()
> > #else /* _KERNEL && UP */
> > #define __storeload_barrier() __compiler_membar()
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
> ___
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 6, 2018, 3:50 PM Tijl Coosemans wrote: > On Fri, 6 Jul 2018 11:09:27 -0700 (PDT) "Rodney W. Grimes" < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes < > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes < > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > > > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > > > > > Author: hselasky > > > > > > > > > Date: Fri Jul 6 10:13:42 2018 > > > > > > > > > New Revision: 336025 > > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336025 > > > > > > > > > > > > > > > > > > Log: > > > > > > > > > Make sure kernel modules built by default are portable > between > > > > UP > > > > > > and > > > > > > > > > SMP systems by extending defined(SMP) to include > > > > > > defined(KLD_MODULE). > > > > > > > > > > > > > > > > > > This is a regression issue after r335873 . > > > > > > > > > > > > > > > > > > Discussed with: mmacy@ > > > > > > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > > > > > > > Though this fixes the issue, it also means that now when > > > > > > > > anyone intentionally builds a UP kernel with modules > > > > > > > > they are getting SMP support in the modules and I am > > > > > > > > not sure they would want that. I know I don't. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On UP systems, these additional opcodes are harmless. They > take a few > > > > > > extra > > > > > > > cycles (since they lock an uncontested bus) and add a couple > extra > > > > memory > > > > > > > barriers (which will be NOPs). On MP systems, atomics now work > by > > > > > > default. > > > > > > > Had we not defaulted like this, all modules built outside of a > kernel > > > > > > build > > > > > > > env would have broken atomics. Given that (a) the > overwhelming > > > > majority > > > > > > > (99% or more) is SMP and (b) the MP code merely adds a few > cycles to > > > > > > what's > > > > > > > already a not-too-expensive operation, this was the right > choice. > > > > > > > > > > > > > > It simply doesn't matter for systems that are relevant to the > project > > > > > > > today. While one could try to optimize this a little (for > example, by > > > > > > > having SMP defined to be 0 or 1, say, and changing all the > ifdef SMP > > > > to > > > > > > if > > > > > > > (defined(SMP) && SMP != 0)), it's likely not going to matter > enough > > > > for > > > > > > > anybody to make the effort. UP on x86 is simply not relevant > enough > > > > to > > > > > > > optimize for it. Even in VMs, people run SMP kernels typically > even > > > > when > > > > > > > they just allocate one CPU to the VM. > > > > > > > > > > > > > > So while we still support the UP config, and we'll let people > build > > > > > > > optimized kernels for x86, we've flipped the switch from > pessimized > > > > for > > > > > > SMP > > > > > > > modules to pessimized for UP modules, which seems like quite > the > > > > > > reasonable > > > > > > > trade-off. > > > > > > > > > > > > > > Were it practical to do so, I'd suggest de-orbiting UP on > x86. > > > > However, > > > > > > > it's a lot of work for not much benefit and we'd need to > invent much > > > > > > crazy > > > > > > > to get there. > > > > > > > > > > > > Trivial to fix this with > > > > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > > > > > > !defined(KLD_UP_MODULES) > > > > > > > > > > > > > > > Nope. Not so trivial. Who defines KLD_UP_MODULES? > > > > > > > > Call it SMP_KLD_MODULES, and it gets defined the same place SMP does. > > > > > > > > > > Not so simple. SMP is defined in the config file, and winds up in one > of > > No problem, that is where I would be defining this anyway, or in the > > latest case removing it and SMP for my UP kernel build. > > > > > the option files. It will be absent for stand alone builds, > > I am ok with that. And it would be reasonable to default to SMP. > > > > > though. These > > > change tweak the default yo be inlined and to include the sequence that > > > works everywhere. > > > > > > > > > > > > And really, it's absolutely not worth it unless someone shows up > with > > > > > numbers to show the old 'function call to optimal routine' is > actually > > > > > faster than the new 'inline to slightly unoptimal code'. Since I > think > > > > the > > > > > function call overhead is larger than the pessmizations, I'm not > sure > > > > what > > > > > the fuss is about. > > > > > > > > I have no issues with the SMP converting from function calls to > > > > inline locks, I just want to retain the exact same code I had > > > > before any of these changes, and that was A UP built system > > > > without any SMP locking. Is it too much to ask to keep what > > > > already worked? > > > > > > > > > > This doesn't
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, 6 Jul 2018 11:09:27 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes < > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes < > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > > > Author: hselasky > > > > > > > > Date: Fri Jul 6 10:13:42 2018 > > > > > > > > New Revision: 336025 > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336025 > > > > > > > > > > > > > > > > Log: > > > > > > > > Make sure kernel modules built by default are portable > > > > > > > > between > > > UP > > > > > and > > > > > > > > SMP systems by extending defined(SMP) to include > > > > > defined(KLD_MODULE). > > > > > > > > > > > > > > > > This is a regression issue after r335873 . > > > > > > > > > > > > > > > > Discussed with: mmacy@ > > > > > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > > > > > Though this fixes the issue, it also means that now when > > > > > > > anyone intentionally builds a UP kernel with modules > > > > > > > they are getting SMP support in the modules and I am > > > > > > > not sure they would want that. I know I don't. > > > > > > > > > > > > > > > > > > > > > > > > > On UP systems, these additional opcodes are harmless. They take a > > > > > > few > > > > > extra > > > > > > cycles (since they lock an uncontested bus) and add a couple extra > > > memory > > > > > > barriers (which will be NOPs). On MP systems, atomics now work by > > > > > default. > > > > > > Had we not defaulted like this, all modules built outside of a > > > > > > kernel > > > > > build > > > > > > env would have broken atomics. Given that (a) the overwhelming > > > majority > > > > > > (99% or more) is SMP and (b) the MP code merely adds a few cycles > > > > > > to > > > > > what's > > > > > > already a not-too-expensive operation, this was the right choice. > > > > > > > > > > > > It simply doesn't matter for systems that are relevant to the > > > > > > project > > > > > > today. While one could try to optimize this a little (for example, > > > > > > by > > > > > > having SMP defined to be 0 or 1, say, and changing all the ifdef > > > > > > SMP > > > to > > > > > if > > > > > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough > > > > > > > > > for > > > > > > anybody to make the effort. UP on x86 is simply not relevant enough > > > > > > > > > to > > > > > > optimize for it. Even in VMs, people run SMP kernels typically even > > > > > > > > > when > > > > > > they just allocate one CPU to the VM. > > > > > > > > > > > > So while we still support the UP config, and we'll let people build > > > > > > optimized kernels for x86, we've flipped the switch from pessimized > > > > > > > > > for > > > > > SMP > > > > > > modules to pessimized for UP modules, which seems like quite the > > > > > reasonable > > > > > > trade-off. > > > > > > > > > > > > Were it practical to do so, I'd suggest de-orbiting UP on x86. > > > However, > > > > > > it's a lot of work for not much benefit and we'd need to invent > > > > > > much > > > > > crazy > > > > > > to get there. > > > > > > > > > > Trivial to fix this with > > > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > > > > > !defined(KLD_UP_MODULES) > > > > > > > > > > > > Nope. Not so trivial. Who defines KLD_UP_MODULES? > > > > > > Call it SMP_KLD_MODULES, and it gets defined the same place SMP does. > > > > > > > Not so simple. SMP is defined in the config file, and winds up in one of > No problem, that is where I would be defining this anyway, or in the > latest case removing it and SMP for my UP kernel build. > > > the option files. It will be absent for stand alone builds, > I am ok with that. And it would be reasonable to default to SMP. > > > though. These > > change tweak the default yo be inlined and to include the sequence that > > works everywhere. > > > > > > > > > And really, it's absolutely not worth it unless someone shows up with > > > > numbers to show the old 'function call to optimal routine' is actually > > > > faster than the new 'inline to slightly unoptimal code'. Since I think > > > the > > > > function call overhead is larger than the pessmizations, I'm not sure > > > what > > > > the fuss is about. > > > > > > I have no issues with the SMP converting from function calls to > > > inline locks, I just want to retain the exact same code I had > > > before any of these changes, and that was A UP built system > > > without any SMP locking. Is it too much to ask to keep what > > > already worked? > > > > > > > This doesn't enable or disable locks in the muted sense. It just changes > > the atomic
Re: svn commit: r336046 - in head/sys: amd64/include i386/include sys
On Fri, Jul 06, 2018 at 07:50:25PM +, Konstantin Belousov wrote: > Author: kib > Date: Fri Jul 6 19:50:25 2018 > New Revision: 336046 > URL: https://svnweb.freebsd.org/changeset/base/336046 > > Log: > Revert to recommit with the proper message. I am sorry for the second mistake of the same sort in the day. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336047 - in head/sys: amd64/include i386/include sys
Author: kib
Date: Fri Jul 6 19:50:44 2018
New Revision: 336047
URL: https://svnweb.freebsd.org/changeset/base/336047
Log:
Expand x86 struct pcpus to UMA_PCPU_ALLOC_SIZE AKA PAGE_SIZE.
This restores counters(9) operation.
Revert r336024. Improve assert of pcpu size on x86.
Reviewed by: mmacy
Sponsored by: The FreeBSD Foundation
Differential revision:https://reviews.freebsd.org/D16163
Modified:
head/sys/amd64/include/counter.h
head/sys/amd64/include/pcpu.h
head/sys/i386/include/pcpu.h
head/sys/sys/pcpu.h
Modified: head/sys/amd64/include/counter.h
==
--- head/sys/amd64/include/counter.hFri Jul 6 19:50:25 2018
(r336046)
+++ head/sys/amd64/include/counter.hFri Jul 6 19:50:44 2018
(r336047)
@@ -83,18 +83,11 @@ counter_u64_zero_inline(counter_u64_t c)
static inline void
counter_u64_add(counter_u64_t c, int64_t inc)
{
- int64_t *p;
-#ifdef notyet
+
__asm __volatile("addq\t%1,%%gs:(%0)"
:
: "r" ((char *)c - (char *)&__pcpu[0]), "ri" (inc)
: "memory", "cc");
-#endif
- /* temporary */
- critical_enter();
- p = zpcpu_get(c);
- *p += inc;
- critical_exit();
}
#endif /* ! __MACHINE_COUNTER_H__ */
Modified: head/sys/amd64/include/pcpu.h
==
--- head/sys/amd64/include/pcpu.h Fri Jul 6 19:50:25 2018
(r336046)
+++ head/sys/amd64/include/pcpu.h Fri Jul 6 19:50:44 2018
(r336047)
@@ -76,8 +76,7 @@
uint32_t pc_pcid_gen; \
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[216] /* be divisor of PAGE_SIZE \
- after cache alignment */
+ char__pad[3288] /* pad to UMA_PCPU_ALLOC_SIZE */
#definePC_DBREG_CMD_NONE 0
#definePC_DBREG_CMD_LOAD 1
Modified: head/sys/i386/include/pcpu.h
==
--- head/sys/i386/include/pcpu.hFri Jul 6 19:50:25 2018
(r336046)
+++ head/sys/i386/include/pcpu.hFri Jul 6 19:50:44 2018
(r336047)
@@ -80,7 +80,7 @@
caddr_t pc_pmap_eh_ptep;
\
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[538]
+ char__pad[3610]
#ifdef _KERNEL
Modified: head/sys/sys/pcpu.h
==
--- head/sys/sys/pcpu.h Fri Jul 6 19:50:25 2018(r336046)
+++ head/sys/sys/pcpu.h Fri Jul 6 19:50:44 2018(r336047)
@@ -185,14 +185,6 @@ struct pcpu {
PCPU_MD_FIELDS;
} __aligned(CACHE_LINE_SIZE);
-#ifdef CTASSERT
-/*
- * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
- * should be denominator of PAGE_SIZE.
- */
-CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
-#endif
-
#ifdef _KERNEL
STAILQ_HEAD(cpuhead, pcpu);
@@ -208,6 +200,19 @@ extern struct pcpu *cpuid_to_pcpu[];
#definecurvidata PCPU_GET(vidata)
#define UMA_PCPU_ALLOC_SIZEPAGE_SIZE
+
+#ifdef CTASSERT
+#if defined(__i386__) || defined(__amd64__)
+/* Required for counters(9) to work on x86. */
+CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE);
+#else
+/*
+ * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
+ * should be denominator of PAGE_SIZE.
+ */
+CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
+#endif /* UMA_PCPU_ALLOC_SIZE && x86 */
+#endif /* CTASSERT */
/* Accessor to elements allocated via UMA_ZONE_PCPU zone. */
static inline void *
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336046 - in head/sys: amd64/include i386/include sys
Author: kib
Date: Fri Jul 6 19:50:25 2018
New Revision: 336046
URL: https://svnweb.freebsd.org/changeset/base/336046
Log:
Revert to recommit with the proper message.
Modified:
head/sys/amd64/include/counter.h
head/sys/amd64/include/pcpu.h
head/sys/i386/include/pcpu.h
head/sys/sys/pcpu.h
Modified: head/sys/amd64/include/counter.h
==
--- head/sys/amd64/include/counter.hFri Jul 6 19:48:47 2018
(r336045)
+++ head/sys/amd64/include/counter.hFri Jul 6 19:50:25 2018
(r336046)
@@ -83,11 +83,18 @@ counter_u64_zero_inline(counter_u64_t c)
static inline void
counter_u64_add(counter_u64_t c, int64_t inc)
{
-
+ int64_t *p;
+#ifdef notyet
__asm __volatile("addq\t%1,%%gs:(%0)"
:
: "r" ((char *)c - (char *)&__pcpu[0]), "ri" (inc)
: "memory", "cc");
+#endif
+ /* temporary */
+ critical_enter();
+ p = zpcpu_get(c);
+ *p += inc;
+ critical_exit();
}
#endif /* ! __MACHINE_COUNTER_H__ */
Modified: head/sys/amd64/include/pcpu.h
==
--- head/sys/amd64/include/pcpu.h Fri Jul 6 19:48:47 2018
(r336045)
+++ head/sys/amd64/include/pcpu.h Fri Jul 6 19:50:25 2018
(r336046)
@@ -76,7 +76,8 @@
uint32_t pc_pcid_gen; \
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[3288] /* pad to UMA_PCPU_ALLOC_SIZE */
+ char__pad[216] /* be divisor of PAGE_SIZE \
+ after cache alignment */
#definePC_DBREG_CMD_NONE 0
#definePC_DBREG_CMD_LOAD 1
Modified: head/sys/i386/include/pcpu.h
==
--- head/sys/i386/include/pcpu.hFri Jul 6 19:48:47 2018
(r336045)
+++ head/sys/i386/include/pcpu.hFri Jul 6 19:50:25 2018
(r336046)
@@ -80,7 +80,7 @@
caddr_t pc_pmap_eh_ptep;
\
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[3610]
+ char__pad[538]
#ifdef _KERNEL
Modified: head/sys/sys/pcpu.h
==
--- head/sys/sys/pcpu.h Fri Jul 6 19:48:47 2018(r336045)
+++ head/sys/sys/pcpu.h Fri Jul 6 19:50:25 2018(r336046)
@@ -185,6 +185,14 @@ struct pcpu {
PCPU_MD_FIELDS;
} __aligned(CACHE_LINE_SIZE);
+#ifdef CTASSERT
+/*
+ * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
+ * should be denominator of PAGE_SIZE.
+ */
+CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
+#endif
+
#ifdef _KERNEL
STAILQ_HEAD(cpuhead, pcpu);
@@ -200,19 +208,6 @@ extern struct pcpu *cpuid_to_pcpu[];
#definecurvidata PCPU_GET(vidata)
#define UMA_PCPU_ALLOC_SIZEPAGE_SIZE
-
-#ifdef CTASSERT
-#if defined(__i386__) || defined(__amd64__)
-/* Required for counters(9) to work on x86. */
-CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE);
-#else
-/*
- * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
- * should be denominator of PAGE_SIZE.
- */
-CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
-#endif /* UMA_PCPU_ALLOC_SIZE && x86 */
-#endif /* CTASSERT */
/* Accessor to elements allocated via UMA_ZONE_PCPU zone. */
static inline void *
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336045 - in head/sys: amd64/include i386/include sys
Author: kib
Date: Fri Jul 6 19:48:47 2018
New Revision: 336045
URL: https://svnweb.freebsd.org/changeset/base/336045
Log:
Save a call to pmap_remove() if entry cannot have any pages mapped.
Due to the way rtld creates mappings for the shared objects, each dso
causes unmap of at least three guard map entries. For instance, in
the buildworld load, this change reduces the amount of pmap_remove()
calls by 1/5.
Profiled by: alc
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Differential revision:https://reviews.freebsd.org/D16148
Modified:
head/sys/amd64/include/counter.h
head/sys/amd64/include/pcpu.h
head/sys/i386/include/pcpu.h
head/sys/sys/pcpu.h
Modified: head/sys/amd64/include/counter.h
==
--- head/sys/amd64/include/counter.hFri Jul 6 19:47:09 2018
(r336044)
+++ head/sys/amd64/include/counter.hFri Jul 6 19:48:47 2018
(r336045)
@@ -83,18 +83,11 @@ counter_u64_zero_inline(counter_u64_t c)
static inline void
counter_u64_add(counter_u64_t c, int64_t inc)
{
- int64_t *p;
-#ifdef notyet
+
__asm __volatile("addq\t%1,%%gs:(%0)"
:
: "r" ((char *)c - (char *)&__pcpu[0]), "ri" (inc)
: "memory", "cc");
-#endif
- /* temporary */
- critical_enter();
- p = zpcpu_get(c);
- *p += inc;
- critical_exit();
}
#endif /* ! __MACHINE_COUNTER_H__ */
Modified: head/sys/amd64/include/pcpu.h
==
--- head/sys/amd64/include/pcpu.h Fri Jul 6 19:47:09 2018
(r336044)
+++ head/sys/amd64/include/pcpu.h Fri Jul 6 19:48:47 2018
(r336045)
@@ -76,8 +76,7 @@
uint32_t pc_pcid_gen; \
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[216] /* be divisor of PAGE_SIZE \
- after cache alignment */
+ char__pad[3288] /* pad to UMA_PCPU_ALLOC_SIZE */
#definePC_DBREG_CMD_NONE 0
#definePC_DBREG_CMD_LOAD 1
Modified: head/sys/i386/include/pcpu.h
==
--- head/sys/i386/include/pcpu.hFri Jul 6 19:47:09 2018
(r336044)
+++ head/sys/i386/include/pcpu.hFri Jul 6 19:48:47 2018
(r336045)
@@ -80,7 +80,7 @@
caddr_t pc_pmap_eh_ptep;
\
uint32_t pc_smp_tlb_done; /* TLB op acknowledgement */\
uint32_t pc_ibpb_set; \
- char__pad[538]
+ char__pad[3610]
#ifdef _KERNEL
Modified: head/sys/sys/pcpu.h
==
--- head/sys/sys/pcpu.h Fri Jul 6 19:47:09 2018(r336044)
+++ head/sys/sys/pcpu.h Fri Jul 6 19:48:47 2018(r336045)
@@ -185,14 +185,6 @@ struct pcpu {
PCPU_MD_FIELDS;
} __aligned(CACHE_LINE_SIZE);
-#ifdef CTASSERT
-/*
- * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
- * should be denominator of PAGE_SIZE.
- */
-CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
-#endif
-
#ifdef _KERNEL
STAILQ_HEAD(cpuhead, pcpu);
@@ -208,6 +200,19 @@ extern struct pcpu *cpuid_to_pcpu[];
#definecurvidata PCPU_GET(vidata)
#define UMA_PCPU_ALLOC_SIZEPAGE_SIZE
+
+#ifdef CTASSERT
+#if defined(__i386__) || defined(__amd64__)
+/* Required for counters(9) to work on x86. */
+CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE);
+#else
+/*
+ * To minimize memory waste in per-cpu UMA zones, size of struct pcpu
+ * should be denominator of PAGE_SIZE.
+ */
+CTASSERT((PAGE_SIZE / sizeof(struct pcpu)) * sizeof(struct pcpu) == PAGE_SIZE);
+#endif /* UMA_PCPU_ALLOC_SIZE && x86 */
+#endif /* CTASSERT */
/* Accessor to elements allocated via UMA_ZONE_PCPU zone. */
static inline void *
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336044 - head/sys/arm64/linux
Author: emaste
Date: Fri Jul 6 19:47:09 2018
New Revision: 336044
URL: https://svnweb.freebsd.org/changeset/base/336044
Log:
Regen arm64 linux sysent after r336043
Modified:
head/sys/arm64/linux/linux_proto.h
head/sys/arm64/linux/linux_systrace_args.c
Modified: head/sys/arm64/linux/linux_proto.h
==
--- head/sys/arm64/linux/linux_proto.h Fri Jul 6 19:44:49 2018
(r336043)
+++ head/sys/arm64/linux/linux_proto.h Fri Jul 6 19:47:09 2018
(r336044)
@@ -811,8 +811,8 @@ struct linux_clone_args {
char flags_l_[PADL_(l_int)]; l_int flags; char flags_r_[PADR_(l_int)];
char stack_l_[PADL_(void *)]; void * stack; char stack_r_[PADR_(void
*)];
char parent_tidptr_l_[PADL_(void *)]; void * parent_tidptr; char
parent_tidptr_r_[PADR_(void *)];
- char child_tidptr_l_[PADL_(void *)]; void * child_tidptr; char
child_tidptr_r_[PADR_(void *)];
char tls_l_[PADL_(void *)]; void * tls; char tls_r_[PADR_(void *)];
+ char child_tidptr_l_[PADL_(void *)]; void * child_tidptr; char
child_tidptr_r_[PADR_(void *)];
};
struct linux_execve_args {
char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)];
Modified: head/sys/arm64/linux/linux_systrace_args.c
==
--- head/sys/arm64/linux/linux_systrace_args.c Fri Jul 6 19:44:49 2018
(r336043)
+++ head/sys/arm64/linux/linux_systrace_args.c Fri Jul 6 19:47:09 2018
(r336044)
@@ -1658,8 +1658,8 @@ systrace_args(int sysnum, void *params, uint64_t *uarg
iarg[0] = p->flags; /* l_int */
uarg[1] = (intptr_t) p->stack; /* void * */
uarg[2] = (intptr_t) p->parent_tidptr; /* void * */
- uarg[3] = (intptr_t) p->child_tidptr; /* void * */
- uarg[4] = (intptr_t) p->tls; /* void * */
+ uarg[3] = (intptr_t) p->tls; /* void * */
+ uarg[4] = (intptr_t) p->child_tidptr; /* void * */
*n_args = 5;
break;
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336043 - head/sys/arm64/linux
Author: emaste
Date: Fri Jul 6 19:44:49 2018
New Revision: 336043
URL: https://svnweb.freebsd.org/changeset/base/336043
Log:
Fix arm64 linuxulator clone() argument order
Linux/arm64 is CLONE_BACKWARDS - i.e., "Architecture has tls passed as
the 4th argument of clone(2), not the 5th one."
The linux clone() syscall has four different permutations of argument
order, depending on architecture - see the #ifdef CONFIG_CLONE_BACKWARDS
maze in Linux's kernel/fork.c.
Sponsored by: Turing Robotic Industries
Modified:
head/sys/arm64/linux/syscalls.master
Modified: head/sys/arm64/linux/syscalls.master
==
--- head/sys/arm64/linux/syscalls.masterFri Jul 6 19:33:58 2018
(r336042)
+++ head/sys/arm64/linux/syscalls.masterFri Jul 6 19:44:49 2018
(r336043)
@@ -403,8 +403,8 @@
218AUE_NULLSTD { int linux_request_key(void); }
219AUE_NULLSTD { int linux_keyctl(void); }
220AUE_RFORK STD { int linux_clone(l_int flags, void *stack, \
- void *parent_tidptr, void *child_tidptr, \
- void *tls); }
+ void *parent_tidptr, void *tls, \
+ void *child_tidptr); }
221AUE_EXECVE STD { int linux_execve(char *path, char **argp, \
char **envp); }
222AUE_MMAPSTD { int linux_mmap2(l_ulong addr, l_ulong len, \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336042 - head/sys/dev/cxgbe/common
Author: np
Date: Fri Jul 6 19:33:58 2018
New Revision: 336042
URL: https://svnweb.freebsd.org/changeset/base/336042
Log:
cxgbe(4): Assume that any unknown flash on the card is 4MB and has 64KB
sectors, instead of refusing to attach to the card.
Submitted by: Casey Leedom @ Chelsio
MFC after:3 days
Sponsored by: Chelsio Communications
Modified:
head/sys/dev/cxgbe/common/t4_hw.c
Modified: head/sys/dev/cxgbe/common/t4_hw.c
==
--- head/sys/dev/cxgbe/common/t4_hw.c Fri Jul 6 19:18:45 2018
(r336041)
+++ head/sys/dev/cxgbe/common/t4_hw.c Fri Jul 6 19:33:58 2018
(r336042)
@@ -7910,7 +7910,7 @@ int t4_get_flash_params(struct adapter *adapter)
int ret;
u32 flashid = 0;
unsigned int part, manufacturer;
- unsigned int density, size;
+ unsigned int density, size = 0;
/*
@@ -7949,7 +7949,7 @@ int t4_get_flash_params(struct adapter *adapter)
*/
manufacturer = flashid & 0xff;
switch (manufacturer) {
- case 0x20: { /* Micron/Numonix */
+ case 0x20: /* Micron/Numonix */
/*
* This Density -> Size decoding table is taken from Micron
* Data Sheets.
@@ -7965,17 +7965,10 @@ int t4_get_flash_params(struct adapter *adapter)
case 0x20: size = 1 << 26; break; /* 64MB */
case 0x21: size = 1 << 27; break; /* 128MB */
case 0x22: size = 1 << 28; break; /* 256MB */
-
- default:
- CH_ERR(adapter, "Micron Flash Part has bad size, "
- "ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
- }
- case 0x9d: { /* ISSI -- Integrated Silicon Solution, Inc. */
+ case 0x9d: /* ISSI -- Integrated Silicon Solution, Inc. */
/*
* This Density -> Size decoding table is taken from ISSI
* Data Sheets.
@@ -7984,17 +7977,10 @@ int t4_get_flash_params(struct adapter *adapter)
switch (density) {
case 0x16: size = 1 << 25; break; /* 32MB */
case 0x17: size = 1 << 26; break; /* 64MB */
-
- default:
- CH_ERR(adapter, "ISSI Flash Part has bad size, "
- "ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
- }
- case 0xc2: { /* Macronix */
+ case 0xc2: /* Macronix */
/*
* This Density -> Size decoding table is taken from Macronix
* Data Sheets.
@@ -8003,17 +7989,10 @@ int t4_get_flash_params(struct adapter *adapter)
switch (density) {
case 0x17: size = 1 << 23; break; /* 8MB */
case 0x18: size = 1 << 24; break; /* 16MB */
-
- default:
- CH_ERR(adapter, "Macronix Flash Part has bad size, "
- "ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
- }
- case 0xef: { /* Winbond */
+ case 0xef: /* Winbond */
/*
* This Density -> Size decoding table is taken from Winbond
* Data Sheets.
@@ -8022,19 +8001,19 @@ int t4_get_flash_params(struct adapter *adapter)
switch (density) {
case 0x17: size = 1 << 23; break; /* 8MB */
case 0x18: size = 1 << 24; break; /* 16MB */
-
- default:
- CH_ERR(adapter, "Winbond Flash Part has bad size, "
- "ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
}
- default:
- CH_ERR(adapter, "Unsupported Flash Part, ID = %#x\n", flashid);
- return -EINVAL;
+ /* If we didn't recognize the FLASH part, that's no real issue: the
+* Hardware/Software contract says that Hardware will _*ALWAYS*_
+* use a FLASH part which is at least 4MB in size and has 64KB
+* sectors. The unrecognized FLASH part is likely to be much larger
+* than 4MB, but that's all we really need.
+*/
+ if (size == 0) {
+ CH_WARN(adapter, "Unknown Flash Part, ID = %#x, assuming
4MB\n", flashid);
+ size = 1 << 22;
}
/*
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to
svn commit: r336041 - head/sys/fs/nfsserver
Author: rmacklem Date: Fri Jul 6 19:18:45 2018 New Revision: 336041 URL: https://svnweb.freebsd.org/changeset/base/336041 Log: Change the pNFS server so that it does not disable a mirrored DS for an NFSERR_STALE error reported via a LayoutReturn. The current FreeBSD client can generate these errors for an operational DS while doing a recovery of a mirror after a mirrored DS has been repaired. I am not sure why these errors occur, but my best current guess is a race between the Layout Recall issued by the kernel code run from pnfsdscopymr(8) and a Read operation on the DS for the file bing copied. The errors are not fatal, since the client falls back on doing I/O through the MDS, which can do the I/O successfully as a proxy. (The fact that the MDS can do this indicates that the file does still exist on the functioning DS.) This change only affects the pNFS server and only when a client does a LayoutReturn with the NFSERR_STALE error report. Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c == --- head/sys/fs/nfsserver/nfs_nfsdstate.c Fri Jul 6 19:10:11 2018 (r336040) +++ head/sys/fs/nfsserver/nfs_nfsdstate.c Fri Jul 6 19:18:45 2018 (r336041) @@ -6750,9 +6750,10 @@ nfsrv_flexlayouterr(struct nfsrv_descript *nd, uint32_ NFSD_DEBUG(4, "flexlayouterr op=%d stat=%d\n", opnum, stat); /* -* Except for NFSERR_ACCES errors, disable the mirror. +* Except for NFSERR_ACCES and NFSERR_STALE errors, +* disable the mirror. */ - if (stat != NFSERR_ACCES) + if (stat != NFSERR_ACCES && stat != NFSERR_STALE) nfsrv_delds(devid, p); } } ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336038 - in head/sys: kern sys
Author: jamie
Date: Fri Jul 6 18:50:22 2018
New Revision: 336038
URL: https://svnweb.freebsd.org/changeset/base/336038
Log:
Change prison_add_vfs() to the more generic prison_add_allow(), which
can add any dynamic allow.* or allow.*.* parameter. Also keep
prison_add_vfs() as a wrapper.
Differential Revision:D16146
Modified:
head/sys/kern/kern_jail.c
head/sys/sys/jail.h
Modified: head/sys/kern/kern_jail.c
==
--- head/sys/kern/kern_jail.c Fri Jul 6 17:39:48 2018(r336037)
+++ head/sys/kern/kern_jail.c Fri Jul 6 18:50:22 2018(r336038)
@@ -3760,37 +3760,43 @@ SYSCTL_JAIL_PARAM(_allow_mount, , CTLTYPE_INT | CTLFLA
"B", "Jail may mount/unmount jail-friendly file systems in general");
/*
- * The VFS system will register jail-aware filesystems here. They each get
- * a parameter allow.mount.xxxfs and a flag to check when a jailed user
- * attempts to mount.
+ * Add a dynamic parameter allow., or allow... Return
+ * its associated bit in the pr_allow bitmask, or zero if the parameter was
+ * not created.
*/
-void
-prison_add_vfs(struct vfsconf *vfsp)
+unsigned
+prison_add_allow(const char *prefix, const char *name, const char
*prefix_descr,
+const char *descr)
{
- char *allow_name, *allow_noname, *mount_allowed;
struct bool_flags *bf;
+ struct sysctl_oid *parent;
+ char *allow_name, *allow_noname, *allowed;
#ifndef NO_SYSCTL_DESCR
- char *descr;
+ char *descr_deprecated;
#endif
unsigned allow_flag;
- if (asprintf(_name, M_PRISON, "allow.mount.%s", vfsp->vfc_name) <
- 0 || asprintf(_noname, M_PRISON, "allow.mount.no%s",
- vfsp->vfc_name) < 0) {
+ if (prefix
+ ? asprintf(_name, M_PRISON, "allow.%s.%s", prefix, name)
+ < 0 ||
+ asprintf(_noname, M_PRISON, "allow.%s.no%s", prefix, name)
+ < 0
+ : asprintf(_name, M_PRISON, "allow.%s", name) < 0 ||
+ asprintf(_noname, M_PRISON, "allow.no%s", name) < 0) {
free(allow_name, M_PRISON);
- return;
+ return 0;
}
/*
-* See if this parameter has already beed added, i.e. if the filesystem
-* was previously loaded/unloaded.
+* See if this parameter has already beed added, i.e. a module was
+* previously loaded/unloaded.
*/
mtx_lock(_mtx);
for (bf = pr_flag_allow;
bf < pr_flag_allow + nitems(pr_flag_allow) && bf->flag != 0;
bf++) {
if (strcmp(bf->name, allow_name) == 0) {
- vfsp->vfc_prison_flag = bf->flag;
+ allow_flag = bf->flag;
goto no_add;
}
}
@@ -3798,7 +3804,7 @@ prison_add_vfs(struct vfsconf *vfsp)
/*
* Find a free bit in prison0's pr_allow, failing if there are none
* (which shouldn't happen as long as we keep track of how many
-* filesystems are jail-aware).
+* potential dynamic flags exist).
*/
for (allow_flag = 1;; allow_flag <<= 1) {
if (allow_flag == 0)
@@ -3815,52 +3821,73 @@ prison_add_vfs(struct vfsconf *vfsp)
for (bf = pr_flag_allow; bf->flag != 0; bf++)
if (bf == pr_flag_allow + nitems(pr_flag_allow)) {
/* This should never happen, but is not fatal. */
+ allow_flag = 0;
goto no_add;
}
prison0.pr_allow |= allow_flag;
bf->name = allow_name;
bf->noname = allow_noname;
bf->flag = allow_flag;
- vfsp->vfc_prison_flag = allow_flag;
mtx_unlock(_mtx);
/*
* Create sysctls for the paramter, and the back-compat global
* permission.
*/
-#ifndef NO_SYSCTL_DESCR
- (void)asprintf(, M_TEMP, "Jail may mount the %s file system",
- vfsp->vfc_name);
-#endif
- (void)SYSCTL_ADD_PROC(NULL,
- SYSCTL_CHILDREN(___security_jail_param_allow_mount),
- OID_AUTO, vfsp->vfc_name, CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE,
+ parent = prefix
+ ? SYSCTL_ADD_NODE(NULL,
+ SYSCTL_CHILDREN(___security_jail_param_allow),
+ OID_AUTO, prefix, 0, 0, prefix_descr)
+ : ___security_jail_param_allow;
+ (void)SYSCTL_ADD_PROC(NULL, SYSCTL_CHILDREN(parent), OID_AUTO,
+ name, CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE,
NULL, 0, sysctl_jail_param, "B", descr);
+ if ((prefix
+? asprintf(, M_TEMP, "%s_%s_allowed", prefix, name)
+: asprintf(, M_TEMP, "%s_allowed", name)) >= 0) {
#ifndef NO_SYSCTL_DESCR
- free(descr, M_TEMP);
+ (void)asprintf(_deprecated, M_TEMP, "%s (deprecated)",
+ descr);
#endif
- if
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes < > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > Author: hselasky > > > > > > > Date: Fri Jul 6 10:13:42 2018 > > > > > > > New Revision: 336025 > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336025 > > > > > > > > > > > > > > Log: > > > > > > > Make sure kernel modules built by default are portable between > > UP > > > > and > > > > > > > SMP systems by extending defined(SMP) to include > > > > defined(KLD_MODULE). > > > > > > > > > > > > > > This is a regression issue after r335873 . > > > > > > > > > > > > > > Discussed with: mmacy@ > > > > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > > > Though this fixes the issue, it also means that now when > > > > > > anyone intentionally builds a UP kernel with modules > > > > > > they are getting SMP support in the modules and I am > > > > > > not sure they would want that. I know I don't. > > > > > > > > > > > > > > > > > > > > > On UP systems, these additional opcodes are harmless. They take a few > > > > extra > > > > > cycles (since they lock an uncontested bus) and add a couple extra > > memory > > > > > barriers (which will be NOPs). On MP systems, atomics now work by > > > > default. > > > > > Had we not defaulted like this, all modules built outside of a kernel > > > > build > > > > > env would have broken atomics. Given that (a) the overwhelming > > majority > > > > > (99% or more) is SMP and (b) the MP code merely adds a few cycles to > > > > what's > > > > > already a not-too-expensive operation, this was the right choice. > > > > > > > > > > It simply doesn't matter for systems that are relevant to the project > > > > > today. While one could try to optimize this a little (for example, by > > > > > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP > > to > > > > if > > > > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough > > for > > > > > anybody to make the effort. UP on x86 is simply not relevant enough > > to > > > > > optimize for it. Even in VMs, people run SMP kernels typically even > > when > > > > > they just allocate one CPU to the VM. > > > > > > > > > > So while we still support the UP config, and we'll let people build > > > > > optimized kernels for x86, we've flipped the switch from pessimized > > for > > > > SMP > > > > > modules to pessimized for UP modules, which seems like quite the > > > > reasonable > > > > > trade-off. > > > > > > > > > > Were it practical to do so, I'd suggest de-orbiting UP on x86. > > However, > > > > > it's a lot of work for not much benefit and we'd need to invent much > > > > crazy > > > > > to get there. > > > > > > > > Trivial to fix this with > > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > > > > !defined(KLD_UP_MODULES) > > > > > > > > > Nope. Not so trivial. Who defines KLD_UP_MODULES? > > > > Call it SMP_KLD_MODULES, and it gets defined the same place SMP does. > > > > Not so simple. SMP is defined in the config file, and winds up in one of No problem, that is where I would be defining this anyway, or in the latest case removing it and SMP for my UP kernel build. > the option files. It will be absent for stand alone builds, I am ok with that. And it would be reasonable to default to SMP. > though. These > change tweak the default yo be inlined and to include the sequence that > works everywhere. > > > > > > And really, it's absolutely not worth it unless someone shows up with > > > numbers to show the old 'function call to optimal routine' is actually > > > faster than the new 'inline to slightly unoptimal code'. Since I think > > the > > > function call overhead is larger than the pessmizations, I'm not sure > > what > > > the fuss is about. > > > > I have no issues with the SMP converting from function calls to > > inline locks, I just want to retain the exact same code I had > > before any of these changes, and that was A UP built system > > without any SMP locking. Is it too much to ask to keep what > > already worked? > > > > This doesn't enable or disable locks in the muted sense. It just changes > the atomic ops for the kernel from a function call to an inlined function. > The inlining is more efficient than the call, even with the overhead added > by always inlining the same stuff. It still is faster than before. > > And userland has done this forever... > > So I honestly think even UP builds are better off, even if it's not hyper > optimized for UP. The lock instruction prefix is minimal overhead (a cycle > I think). I do not believe, and Bruce seems to have evidence, that LOCK is not a one cycle cost. And in my head I know that it can not be that simple as it causes
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 6, 2018, 12:27 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes < > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > Author: hselasky > > > > > > Date: Fri Jul 6 10:13:42 2018 > > > > > > New Revision: 336025 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/336025 > > > > > > > > > > > > Log: > > > > > > Make sure kernel modules built by default are portable between > UP > > > and > > > > > > SMP systems by extending defined(SMP) to include > > > defined(KLD_MODULE). > > > > > > > > > > > > This is a regression issue after r335873 . > > > > > > > > > > > > Discussed with: mmacy@ > > > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > Though this fixes the issue, it also means that now when > > > > > anyone intentionally builds a UP kernel with modules > > > > > they are getting SMP support in the modules and I am > > > > > not sure they would want that. I know I don't. > > > > > > > > > > > > > > > > > On UP systems, these additional opcodes are harmless. They take a few > > > extra > > > > cycles (since they lock an uncontested bus) and add a couple extra > memory > > > > barriers (which will be NOPs). On MP systems, atomics now work by > > > default. > > > > Had we not defaulted like this, all modules built outside of a kernel > > > build > > > > env would have broken atomics. Given that (a) the overwhelming > majority > > > > (99% or more) is SMP and (b) the MP code merely adds a few cycles to > > > what's > > > > already a not-too-expensive operation, this was the right choice. > > > > > > > > It simply doesn't matter for systems that are relevant to the project > > > > today. While one could try to optimize this a little (for example, by > > > > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP > to > > > if > > > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough > for > > > > anybody to make the effort. UP on x86 is simply not relevant enough > to > > > > optimize for it. Even in VMs, people run SMP kernels typically even > when > > > > they just allocate one CPU to the VM. > > > > > > > > So while we still support the UP config, and we'll let people build > > > > optimized kernels for x86, we've flipped the switch from pessimized > for > > > SMP > > > > modules to pessimized for UP modules, which seems like quite the > > > reasonable > > > > trade-off. > > > > > > > > Were it practical to do so, I'd suggest de-orbiting UP on x86. > However, > > > > it's a lot of work for not much benefit and we'd need to invent much > > > crazy > > > > to get there. > > > > > > Trivial to fix this with > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > > > !defined(KLD_UP_MODULES) > > > > > > Nope. Not so trivial. Who defines KLD_UP_MODULES? > > Call it SMP_KLD_MODULES, and it gets defined the same place SMP does. > Not so simple. SMP is defined in the config file, and winds up in one of the option files. It will be absent for stand alone builds, though. These change tweak the default yo be inlined and to include the sequence that works everywhere. > > > And really, it's absolutely not worth it unless someone shows up with > > numbers to show the old 'function call to optimal routine' is actually > > faster than the new 'inline to slightly unoptimal code'. Since I think > the > > function call overhead is larger than the pessmizations, I'm not sure > what > > the fuss is about. > > I have no issues with the SMP converting from function calls to > inline locks, I just want to retain the exact same code I had > before any of these changes, and that was A UP built system > without any SMP locking. Is it too much to ask to keep what > already worked? > This doesn't enable or disable locks in the muted sense. It just changes the atomic ops for the kernel from a function call to an inlined function. The inlining is more efficient than the call, even with the overhead added by always inlining the same stuff. It still is faster than before. And userland has done this forever... So I honestly think even UP builds are better off, even if it's not hyper optimized for UP. The lock instruction prefix is minimal overhead (a cycle I think). This is different than the mutexes we optimize for the UP cases (and which aren't affected by this change). It's really not a big deal. Warner > > > > > > > > > Modified: > > > > > > head/sys/amd64/include/atomic.h > > > > > > head/sys/i386/include/atomic.h > > > > > > > > > > > > Modified: head/sys/amd64/include/atomic.h > > > > > > > > > > > == > > > > > > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018 > > > > > (r336024) > > > > > > +++ head/sys/amd64/include/atomic.h
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, 6 Jul 2018, John Baldwin wrote: On 7/6/18 8:52 AM, Rodney W. Grimes wrote: ... Trivial to fix this with +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || !defined(KLD_UP_MODULES) This is not worth it. Note that we already use LOCK always in userland which is probably far more prevalent than the use in modules. Previously atomics in modules were _function calls_ just to avoid the LOCK. Having the LOCK prefix present even on UP is probably far more efficient than a function call. No, the lock prefix is less efficient. IIRC, on very old systems (~PPro), lock prefixes cost 20 cycles in the UP case. On AthlonXP, they cost about 19 cycles, but function calls (written in C) only cost about 6 cycles. This depends on pipelining, and my test is perhaps too simple since it uses a loop where the pipelinig works especially well (it executes 2 or 3 function calls in parallel). Actually timing on AthlonXP UP: - asm loop: 2 cycles/iteration - "incl mem" in asm loop: 5.85 cycles (but with less alignment, only 3.25 cycles) - "lock; incl mem" in asm loop: 18.9 cycles - function call in C loop to C function doing "incl mem" in asm: 8.35 cycles - function call in C loop to C function doing "lock; incl mem" in asm: 24.95 cycles. Newer CPUs have better pipelining. On Haswell, this gives the strange behaviour that the function call written in C is slightly faster than inline code written in asm: Actual timing on Haswell SMP: - asm loop: 1.16 cycles/iteration - "incl mem" in asm loop: 6.95 cycles - "lock; incl mem" in asm loop: 19.00 cycles - function call in C loop to C function doing "incl mem" in asm: 6 cycles - function call in C loop to C function doing "lock; incl mem" in asm: 26.00 cycles. The C code with the function call executes: loop: callincl incl: pushl %ebp movl%ebp,%esp [lock;] incl mem leave ret incl%ebx cmpl$408000-1,%ebx jbe done I didn't even compile with -fframe-pointer or try clang which would do excessive unrolling. -fframe-pointer takes 3 extra instructions in incl, but these take no extra time. In non-benchmark use, there would be more args for the function call so and the scheduling would be very different so the timing might be very different. I expect the function call would be insignificantly slower except in micro-benchmarks, Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336037 - head/sys/dev/psci
Author: manu
Date: Fri Jul 6 17:39:48 2018
New Revision: 336037
URL: https://svnweb.freebsd.org/changeset/base/336037
Log:
psci: Add \n at the end of printf
Add a \n at the end of the printf if no PSCI function was found otherwise
it mess up the console log.
Modified:
head/sys/dev/psci/psci.c
Modified: head/sys/dev/psci/psci.c
==
--- head/sys/dev/psci/psci.cFri Jul 6 16:51:35 2018(r336036)
+++ head/sys/dev/psci/psci.cFri Jul 6 17:39:48 2018(r336037)
@@ -118,7 +118,7 @@ psci_init(void *dummy)
psci_callfn_t new_callfn;
if (psci_find_callfn(_callfn) != PSCI_RETVAL_SUCCESS) {
- printf("No PSCI/SMCCC call function found");
+ printf("No PSCI/SMCCC call function found\n");
return;
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <
> > > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > >
> > > > > Author: hselasky
> > > > > Date: Fri Jul 6 10:13:42 2018
> > > > > New Revision: 336025
> > > > > URL: https://svnweb.freebsd.org/changeset/base/336025
> > > > >
> > > > > Log:
> > > > > Make sure kernel modules built by default are portable between UP
> > and
> > > > > SMP systems by extending defined(SMP) to include
> > defined(KLD_MODULE).
> > > > >
> > > > > This is a regression issue after r335873 .
> > > > >
> > > > > Discussed with: mmacy@
> > > > > Sponsored by: Mellanox Technologies
> > > >
> > > > Though this fixes the issue, it also means that now when
> > > > anyone intentionally builds a UP kernel with modules
> > > > they are getting SMP support in the modules and I am
> > > > not sure they would want that. I know I don't.
> > > >
> > >
> > >
> > > On UP systems, these additional opcodes are harmless. They take a few
> > extra
> > > cycles (since they lock an uncontested bus) and add a couple extra memory
> > > barriers (which will be NOPs). On MP systems, atomics now work by
> > default.
> > > Had we not defaulted like this, all modules built outside of a kernel
> > build
> > > env would have broken atomics. Given that (a) the overwhelming majority
> > > (99% or more) is SMP and (b) the MP code merely adds a few cycles to
> > what's
> > > already a not-too-expensive operation, this was the right choice.
> > >
> > > It simply doesn't matter for systems that are relevant to the project
> > > today. While one could try to optimize this a little (for example, by
> > > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to
> > if
> > > (defined(SMP) && SMP != 0)), it's likely not going to matter enough for
> > > anybody to make the effort. UP on x86 is simply not relevant enough to
> > > optimize for it. Even in VMs, people run SMP kernels typically even when
> > > they just allocate one CPU to the VM.
> > >
> > > So while we still support the UP config, and we'll let people build
> > > optimized kernels for x86, we've flipped the switch from pessimized for
> > SMP
> > > modules to pessimized for UP modules, which seems like quite the
> > reasonable
> > > trade-off.
> > >
> > > Were it practical to do so, I'd suggest de-orbiting UP on x86. However,
> > > it's a lot of work for not much benefit and we'd need to invent much
> > crazy
> > > to get there.
> >
> > Trivial to fix this with
> > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) ||
> > !defined(KLD_UP_MODULES)
>
>
> Nope. Not so trivial. Who defines KLD_UP_MODULES?
Call it SMP_KLD_MODULES, and it gets defined the same place SMP does.
>
> And really, it's absolutely not worth it unless someone shows up with
> numbers to show the old 'function call to optimal routine' is actually
> faster than the new 'inline to slightly unoptimal code'. Since I think the
> function call overhead is larger than the pessmizations, I'm not sure what
> the fuss is about.
I have no issues with the SMP converting from function calls to
inline locks, I just want to retain the exact same code I had
before any of these changes, and that was A UP built system
without any SMP locking. Is it too much to ask to keep what
already worked?
> > >
> > > > > Modified:
> > > > > head/sys/amd64/include/atomic.h
> > > > > head/sys/i386/include/atomic.h
> > > > >
> > > > > Modified: head/sys/amd64/include/atomic.h
> > > > >
> > > > ==
> > > > > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> > > > (r336024)
> > > > > +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> > > > (r336025)
> > > > > @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(
> > volatile
> > > > u_##TYPE *p, u_
> > > > > * For userland, always use lock prefixes so that the binaries will
> > run
> > > > > * on both SMP and !SMP systems.
> > > > > */
> > > > > -#if defined(SMP) || !defined(_KERNEL)
> > > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > > > > #define MPLOCKED"lock ; "
> > > > > #else
> > > > > #define MPLOCKED
> > > > > @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p,
> > u_int
> > > > v)
> > > > > */
> > > > > #define OFFSETOF_MONITORBUF 0x100
> > > > >
> > > > > -#if defined(SMP)
> > > > > +#if defined(SMP) || defined(KLD_MODULE)
> > > > > static __inline void
> > > > > __storeload_barrier(void)
> > > > > {
> > > > >
> > > > > Modified: head/sys/i386/include/atomic.h
> > > > >
> > > > ==
> > > > > --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> > > > (r336024)
> > > > > +++ head/sys/i386/include/atomic.hFri Jul 6
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> On 7/6/18 8:52 AM, Rodney W. Grimes wrote: > >> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > Author: hselasky > Date: Fri Jul 6 10:13:42 2018 > New Revision: 336025 > URL: https://svnweb.freebsd.org/changeset/base/336025 > > Log: > Make sure kernel modules built by default are portable between UP and > SMP systems by extending defined(SMP) to include defined(KLD_MODULE). > > This is a regression issue after r335873 . > > Discussed with: mmacy@ > Sponsored by: Mellanox Technologies > >>> > >>> Though this fixes the issue, it also means that now when > >>> anyone intentionally builds a UP kernel with modules > >>> they are getting SMP support in the modules and I am > >>> not sure they would want that. I know I don't. > >>> > >> > >> > >> On UP systems, these additional opcodes are harmless. They take a few extra > >> cycles (since they lock an uncontested bus) and add a couple extra memory > >> barriers (which will be NOPs). On MP systems, atomics now work by default. > >> Had we not defaulted like this, all modules built outside of a kernel build > >> env would have broken atomics. Given that (a) the overwhelming majority > >> (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's > >> already a not-too-expensive operation, this was the right choice. > >> > >> It simply doesn't matter for systems that are relevant to the project > >> today. While one could try to optimize this a little (for example, by > >> having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if > >> (defined(SMP) && SMP != 0)), it's likely not going to matter enough for > >> anybody to make the effort. UP on x86 is simply not relevant enough to > >> optimize for it. Even in VMs, people run SMP kernels typically even when > >> they just allocate one CPU to the VM. > >> > >> So while we still support the UP config, and we'll let people build > >> optimized kernels for x86, we've flipped the switch from pessimized for SMP > >> modules to pessimized for UP modules, which seems like quite the reasonable > >> trade-off. > >> > >> Were it practical to do so, I'd suggest de-orbiting UP on x86. However, > >> it's a lot of work for not much benefit and we'd need to invent much crazy > >> to get there. > > > > Trivial to fix this with > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > > !defined(KLD_UP_MODULES) My add probably needs to be && !defined > > This is not worth it. Note that we already use LOCK always in userland > which is probably far more prevalent than the use in modules. > > Previously atomics in modules were _function calls_ just to avoid the LOCK. > Having the LOCK prefix present even on UP is probably far more efficient > than a function call. Which means when I compiled UP before I had nothing, and now this adds useless LOCK perfixes in place of . -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336036 - head/sys/kern
Author: kevans Date: Fri Jul 6 16:51:35 2018 New Revision: 336036 URL: https://svnweb.freebsd.org/changeset/base/336036 Log: kern_environment: Fix SYSINIT ordering The dynamic environment was being initialized at SI_SUB_KMEM, SI_ORDER_ANY. I added the hint-merging at SI_SUB_KMEM, SI_ORDER_ANY as well in r335998 - this can only work by coincidence. Re-do both to operate at SI_SUB_KMEM + 1, SI_ORDER_FIRST and SI_ORDER_SECOND respectively to be safe. It's sufficiently obfuscated away as to when in SU_SUB_KMEM malloc will be available, and the dynamic environment cannot be relied upon there anyways since it's initialized at SI_ORDER_ANY. Reported by: bde Discussed with: bde X-MFC-With: r335998 Modified: head/sys/kern/kern_environment.c head/sys/kern/subr_hints.c Modified: head/sys/kern/kern_environment.c == --- head/sys/kern/kern_environment.cFri Jul 6 16:23:30 2018 (r336035) +++ head/sys/kern/kern_environment.cFri Jul 6 16:51:35 2018 (r336036) @@ -346,7 +346,7 @@ init_dynamic_kenv(void *data __unused) mtx_init(_lock, "kernel environment", NULL, MTX_DEF); dynamic_kenv = 1; } -SYSINIT(kenv, SI_SUB_KMEM, SI_ORDER_ANY, init_dynamic_kenv, NULL); +SYSINIT(kenv, SI_SUB_KMEM + 1, SI_ORDER_FIRST, init_dynamic_kenv, NULL); void freeenv(char *env) Modified: head/sys/kern/subr_hints.c == --- head/sys/kern/subr_hints.c Fri Jul 6 16:23:30 2018(r336035) +++ head/sys/kern/subr_hints.c Fri Jul 6 16:51:35 2018(r336036) @@ -88,7 +88,7 @@ static_hints_to_env(void *data __unused) } /* Any time after dynamic env is setup */ -SYSINIT(hintenv, SI_SUB_KMEM, SI_ORDER_ANY, static_hints_to_env, NULL); +SYSINIT(hintenv, SI_SUB_KMEM + 1, SI_ORDER_SECOND, static_hints_to_env, NULL); /* * Checks the environment to see if we even have any hints. If it has no hints, ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 6, 2018 at 9:52 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <
> > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > > Author: hselasky
> > > > Date: Fri Jul 6 10:13:42 2018
> > > > New Revision: 336025
> > > > URL: https://svnweb.freebsd.org/changeset/base/336025
> > > >
> > > > Log:
> > > > Make sure kernel modules built by default are portable between UP
> and
> > > > SMP systems by extending defined(SMP) to include
> defined(KLD_MODULE).
> > > >
> > > > This is a regression issue after r335873 .
> > > >
> > > > Discussed with: mmacy@
> > > > Sponsored by: Mellanox Technologies
> > >
> > > Though this fixes the issue, it also means that now when
> > > anyone intentionally builds a UP kernel with modules
> > > they are getting SMP support in the modules and I am
> > > not sure they would want that. I know I don't.
> > >
> >
> >
> > On UP systems, these additional opcodes are harmless. They take a few
> extra
> > cycles (since they lock an uncontested bus) and add a couple extra memory
> > barriers (which will be NOPs). On MP systems, atomics now work by
> default.
> > Had we not defaulted like this, all modules built outside of a kernel
> build
> > env would have broken atomics. Given that (a) the overwhelming majority
> > (99% or more) is SMP and (b) the MP code merely adds a few cycles to
> what's
> > already a not-too-expensive operation, this was the right choice.
> >
> > It simply doesn't matter for systems that are relevant to the project
> > today. While one could try to optimize this a little (for example, by
> > having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to
> if
> > (defined(SMP) && SMP != 0)), it's likely not going to matter enough for
> > anybody to make the effort. UP on x86 is simply not relevant enough to
> > optimize for it. Even in VMs, people run SMP kernels typically even when
> > they just allocate one CPU to the VM.
> >
> > So while we still support the UP config, and we'll let people build
> > optimized kernels for x86, we've flipped the switch from pessimized for
> SMP
> > modules to pessimized for UP modules, which seems like quite the
> reasonable
> > trade-off.
> >
> > Were it practical to do so, I'd suggest de-orbiting UP on x86. However,
> > it's a lot of work for not much benefit and we'd need to invent much
> crazy
> > to get there.
>
> Trivial to fix this with
> +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) ||
> !defined(KLD_UP_MODULES)
Nope. Not so trivial. Who defines KLD_UP_MODULES?
And really, it's absolutely not worth it unless someone shows up with
numbers to show the old 'function call to optimal routine' is actually
faster than the new 'inline to slightly unoptimal code'. Since I think the
function call overhead is larger than the pessmizations, I'm not sure what
the fuss is about.
Warner
> >
> > Warner
> >
> >
> > > > Modified:
> > > > head/sys/amd64/include/atomic.h
> > > > head/sys/i386/include/atomic.h
> > > >
> > > > Modified: head/sys/amd64/include/atomic.h
> > > >
> > > ==
> > > > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> > > (r336024)
> > > > +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> > > (r336025)
> > > > @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(
> volatile
> > > u_##TYPE *p, u_
> > > > * For userland, always use lock prefixes so that the binaries will
> run
> > > > * on both SMP and !SMP systems.
> > > > */
> > > > -#if defined(SMP) || !defined(_KERNEL)
> > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > > > #define MPLOCKED"lock ; "
> > > > #else
> > > > #define MPLOCKED
> > > > @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p,
> u_int
> > > v)
> > > > */
> > > > #define OFFSETOF_MONITORBUF 0x100
> > > >
> > > > -#if defined(SMP)
> > > > +#if defined(SMP) || defined(KLD_MODULE)
> > > > static __inline void
> > > > __storeload_barrier(void)
> > > > {
> > > >
> > > > Modified: head/sys/i386/include/atomic.h
> > > >
> > > ==
> > > > --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> > > (r336024)
> > > > +++ head/sys/i386/include/atomic.hFri Jul 6 10:13:42 2018
> > > (r336025)
> > > > @@ -143,7 +143,7 @@ void atomic_subtract_64(volatile
> > > uint64_t *, uint64_t
> > > > * For userland, always use lock prefixes so that the binaries will
> run
> > > > * on both SMP and !SMP systems.
> > > > */
> > > > -#if defined(SMP) || !defined(_KERNEL)
> > > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > > > #define MPLOCKED"lock ; "
> > > > #else
> > > > #define MPLOCKED
> > > > @@ -302,7 +302,7 @@ atomic_testandclear_int(volatile
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On 7/6/18 8:52 AM, Rodney W. Grimes wrote: >> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < >> free...@pdx.rh.cn85.dnsmgr.net> wrote: >> Author: hselasky Date: Fri Jul 6 10:13:42 2018 New Revision: 336025 URL: https://svnweb.freebsd.org/changeset/base/336025 Log: Make sure kernel modules built by default are portable between UP and SMP systems by extending defined(SMP) to include defined(KLD_MODULE). This is a regression issue after r335873 . Discussed with: mmacy@ Sponsored by: Mellanox Technologies >>> >>> Though this fixes the issue, it also means that now when >>> anyone intentionally builds a UP kernel with modules >>> they are getting SMP support in the modules and I am >>> not sure they would want that. I know I don't. >>> >> >> >> On UP systems, these additional opcodes are harmless. They take a few extra >> cycles (since they lock an uncontested bus) and add a couple extra memory >> barriers (which will be NOPs). On MP systems, atomics now work by default. >> Had we not defaulted like this, all modules built outside of a kernel build >> env would have broken atomics. Given that (a) the overwhelming majority >> (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's >> already a not-too-expensive operation, this was the right choice. >> >> It simply doesn't matter for systems that are relevant to the project >> today. While one could try to optimize this a little (for example, by >> having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if >> (defined(SMP) && SMP != 0)), it's likely not going to matter enough for >> anybody to make the effort. UP on x86 is simply not relevant enough to >> optimize for it. Even in VMs, people run SMP kernels typically even when >> they just allocate one CPU to the VM. >> >> So while we still support the UP config, and we'll let people build >> optimized kernels for x86, we've flipped the switch from pessimized for SMP >> modules to pessimized for UP modules, which seems like quite the reasonable >> trade-off. >> >> Were it practical to do so, I'd suggest de-orbiting UP on x86. However, >> it's a lot of work for not much benefit and we'd need to invent much crazy >> to get there. > > Trivial to fix this with > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || > !defined(KLD_UP_MODULES) This is not worth it. Note that we already use LOCK always in userland which is probably far more prevalent than the use in modules. Previously atomics in modules were _function calls_ just to avoid the LOCK. Having the LOCK prefix present even on UP is probably far more efficient than a function call. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336027 - head/gnu/usr.bin/binutils/libbfd
On 7/6/18 4:50 AM, Andrew Turner wrote: > Author: andrew > Date: Fri Jul 6 11:50:59 2018 > New Revision: 336027 > URL: https://svnweb.freebsd.org/changeset/base/336027 > > Log: > Teach binutils that arm64 is a 64bit architecture. This is needed to cross > build from arm64 to other architectures that use binutils. > > Sponsored by: ABT Systems Ltd Perhaps this should just use __LP64__ if we are going to carry a local diff? -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336023 - in head/sys: kern netinet
On 7/6/18 3:03 AM, Brooks Davis wrote: > Author: brooks > Date: Fri Jul 6 10:03:33 2018 > New Revision: 336023 > URL: https://svnweb.freebsd.org/changeset/base/336023 > > Log: > Correct breakage on 32-bit platforms from r335979. Do we still need the kvaddr_t casts after the uintptr_t cast? Are those only required for CHERI (and perhaps if we change the default of how uintptr_t gets converted to an int to default to the vaddr we may find we won't need them at all even on CHERI)? -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336035 - head/usr.bin/cpuset
Author: jamie Date: Fri Jul 6 16:23:30 2018 New Revision: 336035 URL: https://svnweb.freebsd.org/changeset/base/336035 Log: Missed a bit of doc change from r335921. PR: 229266 Modified: head/usr.bin/cpuset/cpuset.1 Modified: head/usr.bin/cpuset/cpuset.1 == --- head/usr.bin/cpuset/cpuset.1Fri Jul 6 16:22:26 2018 (r336034) +++ head/usr.bin/cpuset/cpuset.1Fri Jul 6 16:23:30 2018 (r336035) @@ -52,7 +52,7 @@ .Op Fl c .Op Fl l Ar cpu-list .Op Fl n Ar policy:domain-list -.Op Fl j Ar jailid | Fl p Ar pid | Fl t Ar tid | Fl s Ar setid | Fl x Ar irq +.Op Fl j Ar jail | Fl p Ar pid | Fl t Ar tid | Fl s Ar setid | Fl x Ar irq .Nm .Fl g .Op Fl cir ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336034 - in head: share/misc usr.bin/calendar/calendars
Author: bwidawsk Date: Fri Jul 6 16:22:26 2018 New Revision: 336034 URL: https://svnweb.freebsd.org/changeset/base/336034 Log: Adding myself to committers-src.dot and calendar.freebsd Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D16154 Modified: head/share/misc/committers-src.dot head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/share/misc/committers-src.dot == --- head/share/misc/committers-src.dot Fri Jul 6 13:34:45 2018 (r336033) +++ head/share/misc/committers-src.dot Fri Jul 6 16:22:26 2018 (r336034) @@ -135,6 +135,7 @@ brueffer [label="Christian Brueffer\nbrueffer@FreeBSD. bruno [label="Bruno Ducrot\nbr...@freebsd.org\n2005/07/18"] bryanv [label="Bryan Venteicher\nbry...@freebsd.org\n2012/11/03"] bschmidt [label="Bernhard Schmidt\nbschm...@freebsd.org\n2010/02/06"] +bwidawsk [label="Ben Widawsky\nbwida...@freebsd.org\n2018/07/05"] bz [label="Bjoern A. Zeeb\n...@freebsd.org\n2004/07/27"] cem [label="Conrad Meyer\n...@freebsd.org\n2015/07/05"] chuck [label="Chuck Tuffli\nch...@freebsd.org\n2017/09/06"] @@ -495,6 +496,7 @@ eivind -> des eivind -> rwatson emaste -> achim +emaste -> bwidawsk emaste -> dteske emaste -> kevans emaste -> markj Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdFri Jul 6 13:34:45 2018(r336033) +++ head/usr.bin/calendar/calendars/calendar.freebsdFri Jul 6 16:22:26 2018(r336034) @@ -185,6 +185,7 @@ 05/11 Roman Kurakin born in Moscow, USSR, 1979 05/11 Ulrich Spoerlein born in Schesslitz, Bayern, Germany, 1981 05/13 Pete Fritchman born in Lansdale, Pennsylvania, United States, 1983 +05/13 Ben Widawsky born in New York City, New York, United States, 1982 05/14 Tatsumi Hosokawa born in Tokyo, Japan, 1968 05/14 Shigeyuku Fukushima born in Osaka, Japan, 1974 05/14 Rebecca Cran born in Cambridge, United Kingdom, 1981 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > Author: hselasky
> > > Date: Fri Jul 6 10:13:42 2018
> > > New Revision: 336025
> > > URL: https://svnweb.freebsd.org/changeset/base/336025
> > >
> > > Log:
> > > Make sure kernel modules built by default are portable between UP and
> > > SMP systems by extending defined(SMP) to include defined(KLD_MODULE).
> > >
> > > This is a regression issue after r335873 .
> > >
> > > Discussed with: mmacy@
> > > Sponsored by: Mellanox Technologies
> >
> > Though this fixes the issue, it also means that now when
> > anyone intentionally builds a UP kernel with modules
> > they are getting SMP support in the modules and I am
> > not sure they would want that. I know I don't.
> >
>
>
> On UP systems, these additional opcodes are harmless. They take a few extra
> cycles (since they lock an uncontested bus) and add a couple extra memory
> barriers (which will be NOPs). On MP systems, atomics now work by default.
> Had we not defaulted like this, all modules built outside of a kernel build
> env would have broken atomics. Given that (a) the overwhelming majority
> (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's
> already a not-too-expensive operation, this was the right choice.
>
> It simply doesn't matter for systems that are relevant to the project
> today. While one could try to optimize this a little (for example, by
> having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if
> (defined(SMP) && SMP != 0)), it's likely not going to matter enough for
> anybody to make the effort. UP on x86 is simply not relevant enough to
> optimize for it. Even in VMs, people run SMP kernels typically even when
> they just allocate one CPU to the VM.
>
> So while we still support the UP config, and we'll let people build
> optimized kernels for x86, we've flipped the switch from pessimized for SMP
> modules to pessimized for UP modules, which seems like quite the reasonable
> trade-off.
>
> Were it practical to do so, I'd suggest de-orbiting UP on x86. However,
> it's a lot of work for not much benefit and we'd need to invent much crazy
> to get there.
Trivial to fix this with
+#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) ||
!defined(KLD_UP_MODULES)
>
> Warner
>
>
> > > Modified:
> > > head/sys/amd64/include/atomic.h
> > > head/sys/i386/include/atomic.h
> > >
> > > Modified: head/sys/amd64/include/atomic.h
> > >
> > ==
> > > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> > (r336024)
> > > +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> > (r336025)
> > > @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(volatile
> > u_##TYPE *p, u_
> > > * For userland, always use lock prefixes so that the binaries will run
> > > * on both SMP and !SMP systems.
> > > */
> > > -#if defined(SMP) || !defined(_KERNEL)
> > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > > #define MPLOCKED"lock ; "
> > > #else
> > > #define MPLOCKED
> > > @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p, u_int
> > v)
> > > */
> > > #define OFFSETOF_MONITORBUF 0x100
> > >
> > > -#if defined(SMP)
> > > +#if defined(SMP) || defined(KLD_MODULE)
> > > static __inline void
> > > __storeload_barrier(void)
> > > {
> > >
> > > Modified: head/sys/i386/include/atomic.h
> > >
> > ==
> > > --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> > (r336024)
> > > +++ head/sys/i386/include/atomic.hFri Jul 6 10:13:42 2018
> > (r336025)
> > > @@ -143,7 +143,7 @@ void atomic_subtract_64(volatile
> > uint64_t *, uint64_t
> > > * For userland, always use lock prefixes so that the binaries will run
> > > * on both SMP and !SMP systems.
> > > */
> > > -#if defined(SMP) || !defined(_KERNEL)
> > > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > > #define MPLOCKED"lock ; "
> > > #else
> > > #define MPLOCKED
> > > @@ -302,7 +302,7 @@ atomic_testandclear_int(volatile u_int *p, u_int v)
> > > */
> > >
> > > #if defined(_KERNEL)
> > > -#if defined(SMP)
> > > +#if defined(SMP) || defined(KLD_MODULE)
> > > #define __storeload_barrier() __mbk()
> > > #else /* _KERNEL && UP */
> > > #define __storeload_barrier() __compiler_membar()
> > >
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >
> >
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > Author: hselasky
> > Date: Fri Jul 6 10:13:42 2018
> > New Revision: 336025
> > URL: https://svnweb.freebsd.org/changeset/base/336025
> >
> > Log:
> > Make sure kernel modules built by default are portable between UP and
> > SMP systems by extending defined(SMP) to include defined(KLD_MODULE).
> >
> > This is a regression issue after r335873 .
> >
> > Discussed with: mmacy@
> > Sponsored by: Mellanox Technologies
>
> Though this fixes the issue, it also means that now when
> anyone intentionally builds a UP kernel with modules
> they are getting SMP support in the modules and I am
> not sure they would want that. I know I don't.
>
On UP systems, these additional opcodes are harmless. They take a few extra
cycles (since they lock an uncontested bus) and add a couple extra memory
barriers (which will be NOPs). On MP systems, atomics now work by default.
Had we not defaulted like this, all modules built outside of a kernel build
env would have broken atomics. Given that (a) the overwhelming majority
(99% or more) is SMP and (b) the MP code merely adds a few cycles to what's
already a not-too-expensive operation, this was the right choice.
It simply doesn't matter for systems that are relevant to the project
today. While one could try to optimize this a little (for example, by
having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if
(defined(SMP) && SMP != 0)), it's likely not going to matter enough for
anybody to make the effort. UP on x86 is simply not relevant enough to
optimize for it. Even in VMs, people run SMP kernels typically even when
they just allocate one CPU to the VM.
So while we still support the UP config, and we'll let people build
optimized kernels for x86, we've flipped the switch from pessimized for SMP
modules to pessimized for UP modules, which seems like quite the reasonable
trade-off.
Were it practical to do so, I'd suggest de-orbiting UP on x86. However,
it's a lot of work for not much benefit and we'd need to invent much crazy
to get there.
Warner
> > Modified:
> > head/sys/amd64/include/atomic.h
> > head/sys/i386/include/atomic.h
> >
> > Modified: head/sys/amd64/include/atomic.h
> >
> ==
> > --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> (r336024)
> > +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> (r336025)
> > @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(volatile
> u_##TYPE *p, u_
> > * For userland, always use lock prefixes so that the binaries will run
> > * on both SMP and !SMP systems.
> > */
> > -#if defined(SMP) || !defined(_KERNEL)
> > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > #define MPLOCKED"lock ; "
> > #else
> > #define MPLOCKED
> > @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p, u_int
> v)
> > */
> > #define OFFSETOF_MONITORBUF 0x100
> >
> > -#if defined(SMP)
> > +#if defined(SMP) || defined(KLD_MODULE)
> > static __inline void
> > __storeload_barrier(void)
> > {
> >
> > Modified: head/sys/i386/include/atomic.h
> >
> ==
> > --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> (r336024)
> > +++ head/sys/i386/include/atomic.hFri Jul 6 10:13:42 2018
> (r336025)
> > @@ -143,7 +143,7 @@ void atomic_subtract_64(volatile
> uint64_t *, uint64_t
> > * For userland, always use lock prefixes so that the binaries will run
> > * on both SMP and !SMP systems.
> > */
> > -#if defined(SMP) || !defined(_KERNEL)
> > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> > #define MPLOCKED"lock ; "
> > #else
> > #define MPLOCKED
> > @@ -302,7 +302,7 @@ atomic_testandclear_int(volatile u_int *p, u_int v)
> > */
> >
> > #if defined(_KERNEL)
> > -#if defined(SMP)
> > +#if defined(SMP) || defined(KLD_MODULE)
> > #define __storeload_barrier() __mbk()
> > #else /* _KERNEL && UP */
> > #define __storeload_barrier() __compiler_membar()
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336025 - in head/sys: amd64/include i386/include
> Author: hselasky
> Date: Fri Jul 6 10:13:42 2018
> New Revision: 336025
> URL: https://svnweb.freebsd.org/changeset/base/336025
>
> Log:
> Make sure kernel modules built by default are portable between UP and
> SMP systems by extending defined(SMP) to include defined(KLD_MODULE).
>
> This is a regression issue after r335873 .
>
> Discussed with: mmacy@
> Sponsored by: Mellanox Technologies
Though this fixes the issue, it also means that now when
anyone intentionally builds a UP kernel with modules
they are getting SMP support in the modules and I am
not sure they would want that. I know I don't.
> Modified:
> head/sys/amd64/include/atomic.h
> head/sys/i386/include/atomic.h
>
> Modified: head/sys/amd64/include/atomic.h
> ==
> --- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
> (r336024)
> +++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
> (r336025)
> @@ -132,7 +132,7 @@ void atomic_store_rel_##TYPE(volatile
> u_##TYPE *p, u_
> * For userland, always use lock prefixes so that the binaries will run
> * on both SMP and !SMP systems.
> */
> -#if defined(SMP) || !defined(_KERNEL)
> +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> #define MPLOCKED"lock ; "
> #else
> #define MPLOCKED
> @@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p, u_int v)
> */
> #define OFFSETOF_MONITORBUF 0x100
>
> -#if defined(SMP)
> +#if defined(SMP) || defined(KLD_MODULE)
> static __inline void
> __storeload_barrier(void)
> {
>
> Modified: head/sys/i386/include/atomic.h
> ==
> --- head/sys/i386/include/atomic.hFri Jul 6 10:10:00 2018
> (r336024)
> +++ head/sys/i386/include/atomic.hFri Jul 6 10:13:42 2018
> (r336025)
> @@ -143,7 +143,7 @@ void atomic_subtract_64(volatile uint64_t *,
> uint64_t
> * For userland, always use lock prefixes so that the binaries will run
> * on both SMP and !SMP systems.
> */
> -#if defined(SMP) || !defined(_KERNEL)
> +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
> #define MPLOCKED"lock ; "
> #else
> #define MPLOCKED
> @@ -302,7 +302,7 @@ atomic_testandclear_int(volatile u_int *p, u_int v)
> */
>
> #if defined(_KERNEL)
> -#if defined(SMP)
> +#if defined(SMP) || defined(KLD_MODULE)
> #define __storeload_barrier() __mbk()
> #else /* _KERNEL && UP */
> #define __storeload_barrier() __compiler_membar()
>
>
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336031 - head/usr.bin/top
On 07/06/18 08:49, Ian Lepore wrote: > On Fri, 2018-07-06 at 13:22 +, Sean Bruno wrote: >> Author: sbruno >> Date: Fri Jul 6 13:22:44 2018 >> New Revision: 336031 >> URL: https://svnweb.freebsd.org/changeset/base/336031 >> >> Log: >> r336028 changed next_msg to a char * from char [] of fixed size. Change >> 2nd argument of vsnprintf() to get the strlen of next_msg so that the >> appropriate size is used. >> >> Found with gcc. >> >> /usr.bin/top/display.c: In function 'new_message': >> /usr.bin/top/display.c:963:31: error: >> argument to 'sizeof' in 'vsnprintf' call is the same expression as the >> destination; did you mean to provide an explicit length? >> [-Werror=sizeof-pointer-memaccess] >> vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); >> >> Reviewed by: daichi >> >> Modified: >> head/usr.bin/top/display.c >> >> Modified: head/usr.bin/top/display.c >> == >> --- head/usr.bin/top/display.c Fri Jul 6 12:44:48 2018 >> (r336030) >> +++ head/usr.bin/top/display.c Fri Jul 6 13:22:44 2018 >> (r336031) >> @@ -960,7 +960,7 @@ new_message(int type, const char *msgfmt, ...) >> va_start(args, msgfmt); >> >> /* first, format the message */ >> -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); >> +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); >> >> va_end(args); >> >> > > This fix is incorrect. The original commit that changed next_msg to a > pointer is probably flawed enough to revert and redevelop rather than > try a rolling set of bandaid fixes. > > Whenever setup_buffer() creates a new buffer it will need to store the > size it allocated for use in this vsnprintf() call (and maybe other > places that write directly into next_msg without calling setup_buffer > to reallocate it first, I didn't look). The setup_buffer_bufsiz > variable isn't quite right as-is, because it doesn't include the > 'addlen' value passed to setup_buffer(). > > -- Ian > > Yeah, this isn't going well. I've been poking around in it and I can't see an quick way to do this correctly. sean signature.asc Description: OpenPGP digital signature
Re: svn commit: r336031 - head/usr.bin/top
On Fri, 2018-07-06 at 13:22 +, Sean Bruno wrote: > Author: sbruno > Date: Fri Jul 6 13:22:44 2018 > New Revision: 336031 > URL: https://svnweb.freebsd.org/changeset/base/336031 > > Log: > r336028 changed next_msg to a char * from char [] of fixed size. Change > 2nd argument of vsnprintf() to get the strlen of next_msg so that the > appropriate size is used. > > Found with gcc. > > /usr.bin/top/display.c: In function 'new_message': > /usr.bin/top/display.c:963:31: error: > argument to 'sizeof' in 'vsnprintf' call is the same expression as the > destination; did you mean to provide an explicit length? > [-Werror=sizeof-pointer-memaccess] > vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > > Reviewed by:daichi > > Modified: > head/usr.bin/top/display.c > > Modified: head/usr.bin/top/display.c > == > --- head/usr.bin/top/display.cFri Jul 6 12:44:48 2018 > (r336030) > +++ head/usr.bin/top/display.cFri Jul 6 13:22:44 2018 > (r336031) > @@ -960,7 +960,7 @@ new_message(int type, const char *msgfmt, ...) > va_start(args, msgfmt); > > /* first, format the message */ > -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); > > va_end(args); > > This fix is incorrect. The original commit that changed next_msg to a pointer is probably flawed enough to revert and redevelop rather than try a rolling set of bandaid fixes. Whenever setup_buffer() creates a new buffer it will need to store the size it allocated for use in this vsnprintf() call (and maybe other places that write directly into next_msg without calling setup_buffer to reallocate it first, I didn't look). The setup_buffer_bufsiz variable isn't quite right as-is, because it doesn't include the 'addlen' value passed to setup_buffer(). -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336031 - head/usr.bin/top
On Fri, Jul 06, 2018 at 01:22:44PM +, Sean Bruno wrote: > Author: sbruno > Date: Fri Jul 6 13:22:44 2018 > New Revision: 336031 > URL: https://svnweb.freebsd.org/changeset/base/336031 > > Log: > r336028 changed next_msg to a char * from char [] of fixed size. Change > 2nd argument of vsnprintf() to get the strlen of next_msg so that the > appropriate size is used. > > Found with gcc. > > /usr.bin/top/display.c: In function 'new_message': > /usr.bin/top/display.c:963:31: error: > argument to 'sizeof' in 'vsnprintf' call is the same expression as the > destination; did you mean to provide an explicit length? > [-Werror=sizeof-pointer-memaccess] >vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > > Reviewed by:daichi > > Modified: > head/usr.bin/top/display.c > > Modified: head/usr.bin/top/display.c > == > --- head/usr.bin/top/display.cFri Jul 6 12:44:48 2018 > (r336030) > +++ head/usr.bin/top/display.cFri Jul 6 13:22:44 2018 > (r336031) > @@ -960,7 +960,7 @@ new_message(int type, const char *msgfmt, ...) > va_start(args, msgfmt); > > /* first, format the message */ > -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); I highly suspect that this strlen() call returns zero, always. > > va_end(args); > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336033 - head/sys/netinet
Author: brooks Date: Fri Jul 6 13:34:45 2018 New Revision: 336033 URL: https://svnweb.freebsd.org/changeset/base/336033 Log: One more 32-bit fix for r335979. Reported by: tuexen Modified: head/sys/netinet/sctp_sysctl.c Modified: head/sys/netinet/sctp_sysctl.c == --- head/sys/netinet/sctp_sysctl.c Fri Jul 6 13:31:06 2018 (r336032) +++ head/sys/netinet/sctp_sysctl.c Fri Jul 6 13:34:45 2018 (r336033) @@ -409,7 +409,7 @@ sctp_sysctl_handle_assoclist(SYSCTL_HANDLER_ARGS) xinpcb.total_recvs = inp->total_recvs; xinpcb.total_nospaces = inp->total_nospaces; xinpcb.fragmentation_point = inp->sctp_frag_point; - xinpcb.socket = (kvaddr_t)inp->sctp_socket; + xinpcb.socket = (kvaddr_t)(uintptr_t)inp->sctp_socket; so = inp->sctp_socket; if ((so == NULL) || (!SCTP_IS_LISTENING(inp)) || ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336032 - head/sys/mips/conf
Author: sbruno Date: Fri Jul 6 13:31:06 2018 New Revision: 336032 URL: https://svnweb.freebsd.org/changeset/base/336032 Log: Remove duplicate configuration values as they are already defined in std.AR_MIPS_BASE Modified: head/sys/mips/conf/DIR-825B1 Modified: head/sys/mips/conf/DIR-825B1 == --- head/sys/mips/conf/DIR-825B1Fri Jul 6 13:22:44 2018 (r336031) +++ head/sys/mips/conf/DIR-825B1Fri Jul 6 13:31:06 2018 (r336032) @@ -45,13 +45,6 @@ nodevice ath_rate_sample nooptions INET6 -# Don't include the SCSI/CAM strings in the default build -optionsSCSI_NO_SENSE_STRINGS -optionsSCSI_NO_OP_STRINGS - -# .. And no sysctl strings -optionsNO_SYSCTL_DESCR - # GEOM modules device geom_map# to get access to the SPI flash partitions device geom_uzip # compressed in-memory filesystem hackery! ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r335979 - in head: . lib/libkvm sys/kern sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat
> On 5. Jul 2018, at 15:13, Brooks Davis wrote:
>
> Author: brooks
> Date: Thu Jul 5 13:13:48 2018
> New Revision: 335979
> URL: https://svnweb.freebsd.org/changeset/base/335979
>
> Log:
> Make struct xinpcb and friends word-size independent.
>
> Replace size_t members with ksize_t (uint64_t) and pointer members
> (never used as pointers in userspace, but instead as unique
> idenitifiers) with kvaddr_t (uint64_t). This makes the structs
> identical between 32-bit and 64-bit ABIs.
>
> On 64-bit bit systems, the ABI is maintained. On 32-bit systems,
> this is an ABI breaking change. The ABI of most of these structs
> was previously broken in r315662. This also imposes a small API
> change on userspace consumers who must handle kernel pointers
> becoming virtual addresses.
>
> PR: 228301 (exp-run by antoine)
> Reviewed by: jtl, kib, rwatson (various versions)
> Sponsored by:DARPA, AFRL
> Differential Revision: https://reviews.freebsd.org/D15386
>
> Modified:
> head/UPDATING
> head/lib/libkvm/kvm.h
> head/sys/kern/kern_descrip.c
> head/sys/kern/uipc_socket.c
> head/sys/kern/uipc_usrreq.c
> head/sys/netinet/in_pcb.c
> head/sys/netinet/in_pcb.h
> head/sys/netinet/sctp_sysctl.c
> head/sys/netinet/sctp_uio.h
> head/sys/netinet/tcp_var.h
> head/sys/sys/file.h
> head/sys/sys/param.h
> head/sys/sys/socketvar.h
> head/sys/sys/types.h
> head/sys/sys/unpcb.h
> head/usr.bin/netstat/inet.c
> head/usr.bin/netstat/unix.c
> head/usr.bin/sockstat/sockstat.c
>
> Modified: head/UPDATING
> ==
> --- head/UPDATING Thu Jul 5 11:50:59 2018(r335978)
> +++ head/UPDATING Thu Jul 5 13:13:48 2018(r335979)
> @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
> disable the most expensive debugging functionality run
> "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
>
> +20180705:
> + The ABI of syscalls used by management tools like sockstat and
> + netstat has been broken to allow 32-bit binaries to work on
> + 64-bit kernels without modification. These programs will need
> + to match the kernel in order to function. External programs may
> + require minor modifications to accommodate a change of type in
> + structures from pointers to 64-bit virtual addresses.
> +
> 20180702:
> On i386 and amd64 atomics are now inlined. Out of tree modules using
> atomics will need to be rebuilt.
>
> Modified: head/lib/libkvm/kvm.h
> ==
> --- head/lib/libkvm/kvm.h Thu Jul 5 11:50:59 2018(r335978)
> +++ head/lib/libkvm/kvm.h Thu Jul 5 13:13:48 2018(r335979)
> @@ -61,8 +61,6 @@ typedef __ssize_t ssize_t;
> #define _SSIZE_T_DECLARED
> #endif
>
> -typedef uint64_t kvaddr_t; /* An address in a target
> image. */
> -
> struct kvm_nlist {
> const char *n_name;
> unsigned char n_type;
>
> Modified: head/sys/kern/kern_descrip.c
> ==
> --- head/sys/kern/kern_descrip.c Thu Jul 5 11:50:59 2018
> (r335978)
> +++ head/sys/kern/kern_descrip.c Thu Jul 5 13:13:48 2018
> (r335979)
> @@ -3362,10 +3362,10 @@ sysctl_kern_file(SYSCTL_HANDLER_ARGS)
> if ((fp = fdp->fd_ofiles[n].fde_file) == NULL)
> continue;
> xf.xf_fd = n;
> - xf.xf_file = fp;
> - xf.xf_data = fp->f_data;
> - xf.xf_vnode = fp->f_vnode;
> - xf.xf_type = fp->f_type;
> + xf.xf_file = (kvaddr_t)fp;
> + xf.xf_data = (kvaddr_t)fp->f_data;
> + xf.xf_vnode = (kvaddr_t)fp->f_vnode;
> + xf.xf_type = (kvaddr_t)fp->f_type;
> xf.xf_count = fp->f_count;
> xf.xf_msgcount = 0;
> xf.xf_offset = foffset_get(fp);
>
> Modified: head/sys/kern/uipc_socket.c
> ==
> --- head/sys/kern/uipc_socket.c Thu Jul 5 11:50:59 2018
> (r335978)
> +++ head/sys/kern/uipc_socket.c Thu Jul 5 13:13:48 2018
> (r335979)
> @@ -3985,12 +3985,12 @@ sotoxsocket(struct socket *so, struct xsocket *xso)
> {
>
> xso->xso_len = sizeof *xso;
> - xso->xso_so = so;
> + xso->xso_so = (kvaddr_t)so;
> xso->so_type = so->so_type;
> xso->so_options = so->so_options;
> xso->so_linger = so->so_linger;
> xso->so_state = so->so_state;
> - xso->so_pcb = so->so_pcb;
> + xso->so_pcb = (kvaddr_t)so->so_pcb;
> xso->xso_protocol = so->so_proto->pr_protocol;
> xso->xso_family = so->so_proto->pr_domain->dom_family;
>
svn commit: r336031 - head/usr.bin/top
Author: sbruno Date: Fri Jul 6 13:22:44 2018 New Revision: 336031 URL: https://svnweb.freebsd.org/changeset/base/336031 Log: r336028 changed next_msg to a char * from char [] of fixed size. Change 2nd argument of vsnprintf() to get the strlen of next_msg so that the appropriate size is used. Found with gcc. /usr.bin/top/display.c: In function 'new_message': /usr.bin/top/display.c:963:31: error: argument to 'sizeof' in 'vsnprintf' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); Reviewed by: daichi Modified: head/usr.bin/top/display.c Modified: head/usr.bin/top/display.c == --- head/usr.bin/top/display.c Fri Jul 6 12:44:48 2018(r336030) +++ head/usr.bin/top/display.c Fri Jul 6 13:22:44 2018(r336031) @@ -960,7 +960,7 @@ new_message(int type, const char *msgfmt, ...) va_start(args, msgfmt); /* first, format the message */ -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); va_end(args); ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336028 - head/usr.bin/top
Surely. I think your advice is appropriate. Could you please commit? > 2018/07/06 22:04、Sean Bruno のメール: > > > > On 07/06/18 06:07, Daichi GOTO wrote: >> -static char next_msg[MAX_COLS + 5]; >> +static char *next_msg = NULL; >> static int msglen = 0; >> /* Invariant: msglen is always the length of the message currently displayed >>on the screen (even when next_msg doesn't contain that message). */ > > gcc noticed that a later call to vsnprintf() now has some problems. > /home/sbruno/bsd/wifi/fbsd_head/usr.bin/top/display.c: In function > 'new_message': > /home/sbruno/bsd/wifi/fbsd_head/usr.bin/top/display.c:963:31: error: > argument to 'sizeof' in 'vsnprintf' call is the same expression as the > destination; did you mean to provide an explicit length? > [-Werror=sizeof-pointer-memaccess] > vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > > > I think this needs to be changed > > Index: usr.bin/top/display.c > === > --- usr.bin/top/display.c (revision 336029) > +++ usr.bin/top/display.c (working copy) > @@ -960,7 +960,7 @@ > va_start(args, msgfmt); > > /* first, format the message */ > -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); > +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); > > va_end(args); > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336028 - head/usr.bin/top
On 07/06/18 06:07, Daichi GOTO wrote: > -static char next_msg[MAX_COLS + 5]; > +static char *next_msg = NULL; > static int msglen = 0; > /* Invariant: msglen is always the length of the message currently displayed > on the screen (even when next_msg doesn't contain that message). */ gcc noticed that a later call to vsnprintf() now has some problems. /home/sbruno/bsd/wifi/fbsd_head/usr.bin/top/display.c: In function 'new_message': /home/sbruno/bsd/wifi/fbsd_head/usr.bin/top/display.c:963:31: error: argument to 'sizeof' in 'vsnprintf' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); I think this needs to be changed Index: usr.bin/top/display.c === --- usr.bin/top/display.c (revision 336029) +++ usr.bin/top/display.c (working copy) @@ -960,7 +960,7 @@ va_start(args, msgfmt); /* first, format the message */ -vsnprintf(next_msg, sizeof(next_msg), msgfmt, args); +vsnprintf(next_msg, strlen(next_msg), msgfmt, args); va_end(args); signature.asc Description: OpenPGP digital signature
svn commit: r336030 - head/sys/vm
Author: kib Date: Fri Jul 6 12:44:48 2018 New Revision: 336030 URL: https://svnweb.freebsd.org/changeset/base/336030 Log: Save a call to pmap_remove() if entry cannot have any pages mapped. Due to the way rtld creates mappings for the shared objects, each dso causes unmap of at least three guard map entries. For instance, in the buildworld load, this change reduces the amount of pmap_remove() calls by 1/5. Profiled by: alc Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation MFC after:1 week Differential revision:https://reviews.freebsd.org/D16148 Modified: head/sys/vm/vm_map.c Modified: head/sys/vm/vm_map.c == --- head/sys/vm/vm_map.cFri Jul 6 12:37:46 2018(r336029) +++ head/sys/vm/vm_map.cFri Jul 6 12:44:48 2018(r336030) @@ -3158,7 +3158,14 @@ vm_map_delete(vm_map_t map, vm_offset_t start, vm_offs if (entry->wired_count != 0) vm_map_entry_unwire(map, entry); - pmap_remove(map->pmap, entry->start, entry->end); + /* +* Remove mappings for the pages, but only if the +* mappings could exist. For instance, it does not +* make sense to call pmap_remove() for guard entries. +*/ + if ((entry->eflags & MAP_ENTRY_IS_SUB_MAP) != 0 || + entry->object.vm_object != NULL) + pmap_remove(map->pmap, entry->start, entry->end); /* * Delete the entry only after removing all pmap ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336026 - in head: lib/libnv usr.sbin/config
On Fri, Jul 06, 2018 at 11:23:14AM +, Kyle Evans wrote:
> Author: kevans
> Date: Fri Jul 6 11:23:14 2018
> New Revision: 336026
> URL: https://svnweb.freebsd.org/changeset/base/336026
>
> Log:
> config(8): Fix broken ABI
>
> r336019 introduced ${SRCTOP}/sys to the include paths in order to pull in a
> new sys/{c,}nv.h. This is wrong, because the build tree's ABI isn't
> guaranteed to match what's running on the host system.
>
> Fix instead by removing -I${SRCTOP}/sys and installing the libnv headers
> with `make -C lib/libnv includes`... this may or may not get re-worked in
> the future so that a userland lib isn't installing includes from sys/.
But which libnv the cross-tool config(8) is linked against, the
host-provided one ? libnv which exposes the new headers interface would
come into existence only for the target. Also, I do not think that you can
build this library for cross-tools.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336029 - head/sys/vm
Author: kib
Date: Fri Jul 6 12:37:46 2018
New Revision: 336029
URL: https://svnweb.freebsd.org/changeset/base/336029
Log:
Style: no need for braces around single-line then clause.
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
MFC after:3 days
Differential revision:https://reviews.freebsd.org/D16148
Modified:
head/sys/vm/vm_map.c
Modified: head/sys/vm/vm_map.c
==
--- head/sys/vm/vm_map.cFri Jul 6 12:07:06 2018(r336028)
+++ head/sys/vm/vm_map.cFri Jul 6 12:37:46 2018(r336029)
@@ -3155,9 +3155,8 @@ vm_map_delete(vm_map_t map, vm_offset_t start, vm_offs
* Unwire before removing addresses from the pmap; otherwise,
* unwiring will put the entries back in the pmap.
*/
- if (entry->wired_count != 0) {
+ if (entry->wired_count != 0)
vm_map_entry_unwire(map, entry);
- }
pmap_remove(map->pmap, entry->start, entry->end);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336028 - head/usr.bin/top
Author: daichi
Date: Fri Jul 6 12:07:06 2018
New Revision: 336028
URL: https://svnweb.freebsd.org/changeset/base/336028
Log:
Changed to eliminate the upper limit of command length displayed
by "-a" and expand to match terminal width
Reviewed by: eadler
Approved by: gnn (mentor)
Differential Revision:https://reviews.freebsd.org/D16083
Modified:
head/usr.bin/top/display.c
head/usr.bin/top/machine.c
head/usr.bin/top/screen.c
head/usr.bin/top/top.h
Modified: head/usr.bin/top/display.c
==
--- head/usr.bin/top/display.c Fri Jul 6 11:50:59 2018(r336027)
+++ head/usr.bin/top/display.c Fri Jul 6 12:07:06 2018(r336028)
@@ -57,9 +57,8 @@ FILE *debug;
static int lmpid = 0;
static int last_hi = 0;/* used in u_process and u_endscreen */
static int lastline = 0;
-static int display_width = MAX_COLS;
-#define lineindex(l) ((l)*display_width)
+#define lineindex(l) ((l)*screen_width)
/* things initialized by display_init and used thruout */
@@ -94,6 +93,9 @@ static enum { OFF, ON, ERASE } header_status = ON;
static void summary_format(char *, int *, const char * const *);
static void line_update(char *, char *, int, int);
+static int setup_buffer_bufsiz = 0;
+static char * setup_buffer(char *, int);
+
int x_lastpid = 10;
int y_lastpid = 0;
int x_loadave = 33;
@@ -138,17 +140,9 @@ display_resize(void)
if (lines < 0)
lines = 0;
-/* we don't want more than MAX_COLS columns, since the machine-dependent
- modules make static allocations based on MAX_COLS and we don't want
- to run off the end of their buffers */
-display_width = screen_width;
-if (display_width >= MAX_COLS)
-{
- display_width = MAX_COLS - 1;
-}
/* now, allocate space for the screen buffer */
-screenbuf = calloc(lines, display_width);
+screenbuf = calloc(lines, screen_width);
if (screenbuf == NULL)
{
/* oops! */
@@ -336,7 +330,7 @@ i_timeofday(time_t *tod)
}
static int ltotal = 0;
-static char procstates_buffer[MAX_COLS];
+static char *procstates_buffer = NULL;
/*
* *_procstates(total, brkdn, names) - print the process summary line
@@ -350,6 +344,8 @@ i_procstates(int total, int *brkdn)
{
int i;
+procstates_buffer = setup_buffer(procstates_buffer, 0);
+
/* write current number of processes and remember the value */
printf("%d %s:", total, (ps.thread) ? "threads" :"processes");
ltotal = total;
@@ -372,9 +368,11 @@ i_procstates(int total, int *brkdn)
void
u_procstates(int total, int *brkdn)
{
-static char new[MAX_COLS];
+static char *new = NULL;
int i;
+new = setup_buffer(new, 0);
+
/* update number of processes only if it has changed */
if (ltotal != total)
{
@@ -551,11 +549,13 @@ z_cpustates(void)
*for i_memory ONLY: cursor is on the previous line
*/
-static char memory_buffer[MAX_COLS];
+static char *memory_buffer = NULL;
void
i_memory(int *stats)
{
+memory_buffer = setup_buffer(memory_buffer, 0);
+
fputs("\nMem: ", stdout);
lastline++;
@@ -567,8 +567,10 @@ i_memory(int *stats)
void
u_memory(int *stats)
{
-static char new[MAX_COLS];
+static char *new = NULL;
+new = setup_buffer(new, 0);
+
/* format the new line */
summary_format(new, stats, memory_names);
line_update(memory_buffer, new, x_mem, y_mem);
@@ -580,11 +582,13 @@ u_memory(int *stats)
* Assumptions: cursor is on "lastline"
*for i_arc ONLY: cursor is on the previous line
*/
-static char arc_buffer[MAX_COLS];
+static char *arc_buffer = NULL;
void
i_arc(int *stats)
{
+arc_buffer = setup_buffer(arc_buffer, 0);
+
if (arc_names == NULL)
return;
@@ -599,8 +603,10 @@ i_arc(int *stats)
void
u_arc(int *stats)
{
-static char new[MAX_COLS];
+static char *new = NULL;
+new = setup_buffer(new, 0);
+
if (arc_names == NULL)
return;
@@ -616,11 +622,13 @@ u_arc(int *stats)
* Assumptions: cursor is on "lastline"
*for i_carc ONLY: cursor is on the previous line
*/
-static char carc_buffer[MAX_COLS];
+static char *carc_buffer = NULL;
void
i_carc(int *stats)
{
+carc_buffer = setup_buffer(carc_buffer, 0);
+
if (carc_names == NULL)
return;
@@ -635,8 +643,10 @@ i_carc(int *stats)
void
u_carc(int *stats)
{
-static char new[MAX_COLS];
+static char *new = NULL;
+new = setup_buffer(new, 0);
+
if (carc_names == NULL)
return;
@@ -652,11 +662,13 @@ u_carc(int *stats)
*for i_swap ONLY: cursor is on the previous line
*/
-static char swap_buffer[MAX_COLS];
+static char *swap_buffer = NULL;
void
i_swap(int *stats)
{
+swap_buffer = setup_buffer(swap_buffer, 0);
+
fputs("\nSwap: ", stdout);
lastline++;
@@ -668,8 +680,10 @@
svn commit: r336027 - head/gnu/usr.bin/binutils/libbfd
Author: andrew
Date: Fri Jul 6 11:50:59 2018
New Revision: 336027
URL: https://svnweb.freebsd.org/changeset/base/336027
Log:
Teach binutils that arm64 is a 64bit architecture. This is needed to cross
build from arm64 to other architectures that use binutils.
Sponsored by: ABT Systems Ltd
Modified:
head/gnu/usr.bin/binutils/libbfd/bfd.h
Modified: head/gnu/usr.bin/binutils/libbfd/bfd.h
==
--- head/gnu/usr.bin/binutils/libbfd/bfd.h Fri Jul 6 11:23:14 2018
(r336026)
+++ head/gnu/usr.bin/binutils/libbfd/bfd.h Fri Jul 6 11:50:59 2018
(r336027)
@@ -85,7 +85,7 @@ extern "C" {
#define BFD_HOST_64BIT_LONG 0
#define BFD_HOST_64_BIT long long
#define BFD_HOST_U_64_BIT unsigned long long
-#elif defined(__alpha__) || defined(__sparc64__) || defined(__amd64__)
+#elif defined(__alpha__) || defined(__sparc64__) || defined(__amd64__) ||
defined(__aarch64__)
#define BFD_HOST_64BIT_LONG 1
#define BFD_HOST_64_BIT long
#define BFD_HOST_U_64_BIT unsigned long
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336019 - in head: . usr.sbin/config
On Fri, Jul 6, 2018 at 1:08 AM, Bryan Drewery wrote:
> On 7/5/18 6:53 PM, Kyle Evans wrote:
>> On Thu, Jul 5, 2018 at 8:11 PM, Kyle Evans wrote:
>>> Author: kevans
>>> Date: Fri Jul 6 01:11:06 2018
>>> New Revision: 336019
>>> URL: https://svnweb.freebsd.org/changeset/base/336019
>>>
>>> Log:
>>> config(8): De-dupe hint/env vars within a single file
>>>
>>> r335653 flipped the order in which hints/env files are concatenated to
>>> match
>>> the order in which vars are processed by the kernel. This is the other
>>> hammer to drop.
>>>
>>> Use nv(9) to de-dupe entries within a single `hint` or `env` file, using
>>> the
>>> latest value specified for a key. This leaves some duplicates if a
>>> variable
>>> is specified in multiple hint/env files or via `envvar` in a kernel
>>> config,
>>> but the reversed order of concatenation (from r335653) makes this a
>>> non-issue as the latest-specified version will be seen first.
>>>
>>> This change also silently rewrote hint bits to use the same sanitization
>>> process that ian@ wrote for r335642. To the kernel, hints and env vars are
>>> basically the same thing through early boot, then get merged into the
>>> dynamic environment once kmem becomes available and the dynamic
>>> environment
>>> is created. They should be subjected to the same restrictions.
>>>
>>> libnv has been added to -legacy for the time being to support the build of
>>> config(8) with the new cnvlist API.
>>>
>>> Tested with: universe (11 host & 12 host)
>>> MFC after:1 month
>>>
>>
>> This seems to be causing pretty consistent config(8) failures on CI,
>> kernels with neither hints nor environment variables, that neither of
>> my universe builds nor any of my post-commit builds can reproduce. Can
>> anyone else reproduce these failures that might be willing to give me
>> a hint as to what kind of setup causes this?
>>
>> 01:47:58 cd /usr/src/sys/arm/conf;
>> PATH=/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
>> config -d /usr/obj/usr/src/arm.armv7/sys/GENERIC -I
>> '/usr/src/sys/arm/conf' '/usr/src/sys/arm/conf/GENERIC'
>> 01:47:58 config: /usr/src/sys/arm/conf/GENERIC: No error: 0
>>
>
> I've seen this error with broken ABI. The -I${SRCTOP}/sys on the config
> build may be contributing to the problem since sys/stat.h is ino64 and
> the builder may not be. Really should not be bringing in the source
> sys/ directory for any of the early host tool phases. There's some hack
> patterns to bring in a limited amount of headers but in this case the
> headers should be getting staged somewhere already.
> Note legacy:
> ${MAKE} DIRPRFX=${_tool}/ DESTDIR=${WORLDTMP}/legacy includes; \
>
> So -IWORLDTMP/legacy/sys should find the nv headers. This is already
> included via:
> tools/build/mk/Makefile.boot:CFLAGS+= -I${WORLDTMP}/legacy/usr/include
> Which is brought in for bootstrap-tools though via:
> MAKEFLAGS="-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}"
>
Ahh, that explains it. I did a little bit of a dirty hack in r336026
to install the needed libnv headers with libnv- otherwise, we'd still
be relying on the host libnv headers since sys/ bits don't normally
get pulled in with `make includes` (from the look of it). It feels
wrong to have a userland lib installing headers into
${INCLUDEDIR}/sys, but I think that's a libnv problem. This should fix
the observed problem with CI for the time being.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336026 - in head: lib/libnv usr.sbin/config
Author: kevans
Date: Fri Jul 6 11:23:14 2018
New Revision: 336026
URL: https://svnweb.freebsd.org/changeset/base/336026
Log:
config(8): Fix broken ABI
r336019 introduced ${SRCTOP}/sys to the include paths in order to pull in a
new sys/{c,}nv.h. This is wrong, because the build tree's ABI isn't
guaranteed to match what's running on the host system.
Fix instead by removing -I${SRCTOP}/sys and installing the libnv headers
with `make -C lib/libnv includes`... this may or may not get re-worked in
the future so that a userland lib isn't installing includes from sys/.
Reported by: bdrewery
Modified:
head/lib/libnv/Makefile
head/usr.sbin/config/Makefile
Modified: head/lib/libnv/Makefile
==
--- head/lib/libnv/Makefile Fri Jul 6 10:13:42 2018(r336025)
+++ head/lib/libnv/Makefile Fri Jul 6 11:23:14 2018(r336026)
@@ -17,6 +17,9 @@ SRCS+=msgio.c
SRCS+= nvlist.c
SRCS+= nvpair.c
+INCSDIR= ${INCLUDEDIR}/sys
+INCS= ${SRCTOP}/sys/sys/cnv.h ${SRCTOP}/sys/sys/nv.h
+
HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests
Modified: head/usr.sbin/config/Makefile
==
--- head/usr.sbin/config/Makefile Fri Jul 6 10:13:42 2018
(r336025)
+++ head/usr.sbin/config/Makefile Fri Jul 6 11:23:14 2018
(r336026)
@@ -14,7 +14,7 @@ kernconf.c: kernconf.tmpl
${FILE2C} 'char kernconfstr[] = {' ',0};' < \
${SRCDIR}/kernconf.tmpl > kernconf.c
-CFLAGS+= -I. -I${SRCDIR} -I${SRCTOP}/sys
+CFLAGS+= -I. -I${SRCDIR}
NO_WMISSING_VARIABLE_DECLARATIONS=
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336025 - in head/sys: amd64/include i386/include
Author: hselasky
Date: Fri Jul 6 10:13:42 2018
New Revision: 336025
URL: https://svnweb.freebsd.org/changeset/base/336025
Log:
Make sure kernel modules built by default are portable between UP and
SMP systems by extending defined(SMP) to include defined(KLD_MODULE).
This is a regression issue after r335873 .
Discussed with: mmacy@
Sponsored by: Mellanox Technologies
Modified:
head/sys/amd64/include/atomic.h
head/sys/i386/include/atomic.h
Modified: head/sys/amd64/include/atomic.h
==
--- head/sys/amd64/include/atomic.h Fri Jul 6 10:10:00 2018
(r336024)
+++ head/sys/amd64/include/atomic.h Fri Jul 6 10:13:42 2018
(r336025)
@@ -132,7 +132,7 @@ voidatomic_store_rel_##TYPE(volatile
u_##TYPE *p, u_
* For userland, always use lock prefixes so that the binaries will run
* on both SMP and !SMP systems.
*/
-#if defined(SMP) || !defined(_KERNEL)
+#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
#defineMPLOCKED"lock ; "
#else
#defineMPLOCKED
@@ -354,7 +354,7 @@ atomic_testandclear_long(volatile u_long *p, u_int v)
*/
#defineOFFSETOF_MONITORBUF 0x100
-#if defined(SMP)
+#if defined(SMP) || defined(KLD_MODULE)
static __inline void
__storeload_barrier(void)
{
Modified: head/sys/i386/include/atomic.h
==
--- head/sys/i386/include/atomic.h Fri Jul 6 10:10:00 2018
(r336024)
+++ head/sys/i386/include/atomic.h Fri Jul 6 10:13:42 2018
(r336025)
@@ -143,7 +143,7 @@ voidatomic_subtract_64(volatile uint64_t *,
uint64_t
* For userland, always use lock prefixes so that the binaries will run
* on both SMP and !SMP systems.
*/
-#if defined(SMP) || !defined(_KERNEL)
+#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
#defineMPLOCKED"lock ; "
#else
#defineMPLOCKED
@@ -302,7 +302,7 @@ atomic_testandclear_int(volatile u_int *p, u_int v)
*/
#if defined(_KERNEL)
-#if defined(SMP)
+#if defined(SMP) || defined(KLD_MODULE)
#define__storeload_barrier() __mbk()
#else /* _KERNEL && UP */
#define__storeload_barrier() __compiler_membar()
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336024 - head/sys/amd64/include
Author: mmacy
Date: Fri Jul 6 10:10:00 2018
New Revision: 336024
URL: https://svnweb.freebsd.org/changeset/base/336024
Log:
counter(9): unbreak amd64 following r336020
Apply temporary fix to counter until daylight hours.
The fact that the assembly for counter_u64_add relied on the sizeof(struct
pcpu) was
the basis for the otherwise arbitrary offset never came up in D15933.
critical_{enter,exit} is now inline so the only real added overhead is the
added (mostly false) conditional branch in exit.
Modified:
head/sys/amd64/include/counter.h
Modified: head/sys/amd64/include/counter.h
==
--- head/sys/amd64/include/counter.hFri Jul 6 10:03:33 2018
(r336023)
+++ head/sys/amd64/include/counter.hFri Jul 6 10:10:00 2018
(r336024)
@@ -83,11 +83,18 @@ counter_u64_zero_inline(counter_u64_t c)
static inline void
counter_u64_add(counter_u64_t c, int64_t inc)
{
-
+ int64_t *p;
+#ifdef notyet
__asm __volatile("addq\t%1,%%gs:(%0)"
:
: "r" ((char *)c - (char *)&__pcpu[0]), "ri" (inc)
: "memory", "cc");
+#endif
+ /* temporary */
+ critical_enter();
+ p = zpcpu_get(c);
+ *p += inc;
+ critical_exit();
}
#endif /* ! __MACHINE_COUNTER_H__ */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336023 - in head/sys: kern netinet
Author: brooks
Date: Fri Jul 6 10:03:33 2018
New Revision: 336023
URL: https://svnweb.freebsd.org/changeset/base/336023
Log:
Correct breakage on 32-bit platforms from r335979.
Modified:
head/sys/kern/kern_descrip.c
head/sys/kern/uipc_socket.c
head/sys/kern/uipc_usrreq.c
head/sys/netinet/in_pcb.c
Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cFri Jul 6 06:21:24 2018
(r336022)
+++ head/sys/kern/kern_descrip.cFri Jul 6 10:03:33 2018
(r336023)
@@ -3362,10 +3362,10 @@ sysctl_kern_file(SYSCTL_HANDLER_ARGS)
if ((fp = fdp->fd_ofiles[n].fde_file) == NULL)
continue;
xf.xf_fd = n;
- xf.xf_file = (kvaddr_t)fp;
- xf.xf_data = (kvaddr_t)fp->f_data;
- xf.xf_vnode = (kvaddr_t)fp->f_vnode;
- xf.xf_type = (kvaddr_t)fp->f_type;
+ xf.xf_file = (kvaddr_t)(uintptr_t)fp;
+ xf.xf_data = (kvaddr_t)(uintptr_t)fp->f_data;
+ xf.xf_vnode = (kvaddr_t)(uintptr_t)fp->f_vnode;
+ xf.xf_type = (kvaddr_t)(uintptr_t)fp->f_type;
xf.xf_count = fp->f_count;
xf.xf_msgcount = 0;
xf.xf_offset = foffset_get(fp);
Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Fri Jul 6 06:21:24 2018(r336022)
+++ head/sys/kern/uipc_socket.c Fri Jul 6 10:03:33 2018(r336023)
@@ -3985,12 +3985,12 @@ sotoxsocket(struct socket *so, struct xsocket *xso)
{
xso->xso_len = sizeof *xso;
- xso->xso_so = (kvaddr_t)so;
+ xso->xso_so = (kvaddr_t)(uintptr_t)so;
xso->so_type = so->so_type;
xso->so_options = so->so_options;
xso->so_linger = so->so_linger;
xso->so_state = so->so_state;
- xso->so_pcb = (kvaddr_t)so->so_pcb;
+ xso->so_pcb = (kvaddr_t)(uintptr_t)so->so_pcb;
xso->xso_protocol = so->so_proto->pr_protocol;
xso->xso_family = so->so_proto->pr_domain->dom_family;
xso->so_timeo = so->so_timeo;
Modified: head/sys/kern/uipc_usrreq.c
==
--- head/sys/kern/uipc_usrreq.c Fri Jul 6 06:21:24 2018(r336022)
+++ head/sys/kern/uipc_usrreq.c Fri Jul 6 10:03:33 2018(r336023)
@@ -1853,7 +1853,7 @@ unp_pcblist(SYSCTL_HANDLER_ARGS)
if (freeunp == 0 && unp->unp_gencnt <= gencnt) {
xu->xu_len = sizeof *xu;
- xu->xu_unpp = (kvaddr_t)unp;
+ xu->xu_unpp = (kvaddr_t)(uintptr_t)unp;
/*
* XXX - need more locking here to protect against
* connect/disconnect races for SMP.
@@ -1870,10 +1870,12 @@ unp_pcblist(SYSCTL_HANDLER_ARGS)
unp->unp_conn->unp_addr->sun_len);
else
bzero(>xu_caddr, sizeof(xu->xu_caddr));
- xu->unp_vnode = (kvaddr_t)unp->unp_vnode;
- xu->unp_conn = (kvaddr_t)unp->unp_conn;
- xu->xu_firstref = (kvaddr_t)LIST_FIRST(>unp_refs);
- xu->xu_nextref = (kvaddr_t)LIST_NEXT(unp, unp_reflink);
+ xu->unp_vnode = (kvaddr_t)(uintptr_t)unp->unp_vnode;
+ xu->unp_conn = (kvaddr_t)(uintptr_t)unp->unp_conn;
+ xu->xu_firstref =
+ (kvaddr_t)(uintptr_t)LIST_FIRST(>unp_refs);
+ xu->xu_nextref =
+ (kvaddr_t)(uintptr_t)LIST_NEXT(unp, unp_reflink);
xu->unp_gencnt = unp->unp_gencnt;
sotoxsocket(unp->unp_socket, >xu_socket);
UNP_PCB_UNLOCK(unp);
Modified: head/sys/netinet/in_pcb.c
==
--- head/sys/netinet/in_pcb.c Fri Jul 6 06:21:24 2018(r336022)
+++ head/sys/netinet/in_pcb.c Fri Jul 6 10:03:33 2018(r336023)
@@ -2906,7 +2906,7 @@ in_pcbtoxinpcb(const struct inpcb *inp, struct xinpcb
bzero(>xi_socket, sizeof(struct xsocket));
bcopy(>inp_inc, >inp_inc, sizeof(struct in_conninfo));
xi->inp_gencnt = inp->inp_gencnt;
- xi->inp_ppcb = (kvaddr_t)inp->inp_ppcb;
+ xi->inp_ppcb = (kvaddr_t)(uintptr_t)inp->inp_ppcb;
xi->inp_flow = inp->inp_flow;
xi->inp_flowid = inp->inp_flowid;
xi->inp_flowtype = inp->inp_flowtype;
___
svn-src-head@freebsd.org mailing list
Re: svn commit: r335979 - in head: . lib/libkvm sys/kern sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat
Sorry about that. I'm working on it. -- brooks On Thu, Jul 05, 2018 at 06:45:33PM -0700, Matthew Macy wrote: > this breaks the MIPS builds. > > On Thu, Jul 5, 2018 at 9:33 AM, Brooks Davis wrote: > > On Thu, Jul 05, 2018 at 09:10:54AM -0700, Ravi Pokala wrote: > >> Hi Brooks, > >> > >> -Original Message- > >> From: on behalf of Brooks Davis > >> > >> Date: 2018-07-05, Thursday at 06:13 > >> To: , , > >> > >> Subject: svn commit: r335979 - in head: . lib/libkvm sys/kern sys/netinet > >> sys/sys usr.bin/netstat usr.bin/sockstat > >> > >> > Author: brooks > >> > Date: Thu Jul 5 13:13:48 2018 > >> > New Revision: 335979 > >> > URL: https://svnweb.freebsd.org/changeset/base/335979 > >> > > >> > Log: > >> > Make struct xinpcb and friends word-size independent. > >> > > >> > Replace size_t members with ksize_t (uint64_t) and pointer members > >> > (never used as pointers in userspace, but instead as unique > >> > idenitifiers) with kvaddr_t (uint64_t). This makes the structs > >> > identical between 32-bit and 64-bit ABIs. > >> ... > >> > Modified: head/UPDATING > >> > == > >> > --- head/UPDATING Thu Jul 5 11:50:59 2018(r335978) > >> > +++ head/UPDATING Thu Jul 5 13:13:48 2018(r335979) > >> > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: > >> > disable the most expensive debugging functionality run > >> > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > >> > > >> > +20180705: > >> > + The ABI of syscalls used by management tools like sockstat and > >> > + netstat has been broken to allow 32-bit binaries to work on > >> > + 64-bit kernels without modification. > >> > >> Isn't that what the compat32 layer is for? > > > > compat32 isn't magic. If one tried, one could hardly design structures > > to make 32-bit compat harder then the previous versions. It's certainly > > possible to make work, but quite annoying. Since the ABI of most these > > structures was already broken for 12, I chose this approach as it is > > quite trivial. > > > >> > These programs will need > >> > + to match the kernel in order to function. External programs may > >> > + require minor modifications to accommodate a change of type in > >> > + structures from pointers to 64-bit virtual addresses. > >> > >> Doesn't this contradict the earlier statement about letting things run > >> unmodified? > > > > Unmodified post this commit. We already don't support netstat and > > sockstat from 11 on 12 in any architecture combination. > > > > -- Brooks > signature.asc Description: PGP signature
Re: svn commit: r336017 - in head: include/rpcsvc lib/libutil libexec/rpc.rquotad sys/cddl/contrib/opensolaris/uts/common/fs/zfs usr.bin/quota
Hi!
Unfortunately this patch is not quite correct regarding how you define the RPC
interfaces.
The versioning in RPC is to specify the interface, much like versioning in
shared library.
If you have RPC program version 1, exposing functions get_quota() and
get_active_quota(), and you want to expose new function, you should introduce
new version.
The best example about this logic is in mount.x - there you can see how they
have done 2 versions of the interface, expanding the list of exported functions.
The problem is, to create connection with server, you specify pair, and if supported, you will get the corresponding handle. Now you
can have situation with mixed new and old interfaces (sharing the same version
number) but the exported functions are not the same.
rgds,
toomas
> On 6 Jul 2018, at 01:56, Sean Eric Fagan wrote:
>
> Author: sef
> Date: Thu Jul 5 22:56:13 2018
> New Revision: 336017
> URL: https://svnweb.freebsd.org/changeset/base/336017
>
> Log:
> This exposes ZFS user and group quotas via the normal
> quatactl(2) mechanism. (Read-only at this point, however.)
> In particular, this is to allow rpc.rquotad query quotas
> for NFS mounts, allowing users to see their quotas on the
> hosts using the datasets.
>
> The changes specifically:
>
> * Add new RPC entry points for querying quotas.
> * Changes the library routines to allow non-UFS quotas.
> * Changes rquotad to check for quotas on mounted filesystems,
> rather than being limited to entries in /etc/fstab
> * Lastly, adds a VFS entry-point for ZFS to query quotas.
>
> Note that this makes one unavoidable behavioural change: if quotas
> are enabled, then they can be queried, as opposed to the current
> method of checking for quotas being specified in fstab. (With
> ZFS, if there are user or group quotas, they're used, always.)
>
> Reviewed by: delphij, mav
> Approved by: mav
> Sponsored by:iXsystems Inc
> Differential Revision: https://reviews.freebsd.org/D15886
>
> Modified:
> head/include/rpcsvc/rquota.x
> head/lib/libutil/quotafile.c
> head/libexec/rpc.rquotad/rquotad.c
> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
> head/usr.bin/quota/quota.c
>
> Modified: head/include/rpcsvc/rquota.x
> ==
> --- head/include/rpcsvc/rquota.x Thu Jul 5 21:38:54 2018
> (r336016)
> +++ head/include/rpcsvc/rquota.x Thu Jul 5 22:56:13 2018
> (r336017)
> @@ -1,24 +1,55 @@
> +/* @(#)rquota.x 2.1 88/08/01 4.0 RPCSRC */
> +/* @(#)rquota.x 1.2 87/09/20 Copyr 1987 Sun Micro */
> +
> /*
> * Remote quota protocol
> * Requires unix authentication
> */
>
> #ifndef RPC_HDR
> -%#ifndef lint
> -%/*static char sccsid[] = "from: @(#)rquota.x 1.2 87/09/20 Copyr 1987 Sun
> Micro";*/
> -%/*static char sccsid[] = "from: @(#)rquota.x2.1 88/08/01 4.0
> RPCSRC";*/
> -%#endif /* not lint */
> %#include
> %__FBSDID("$FreeBSD$");
> #endif
>
> const RQ_PATHLEN = 1024;
>
> +struct sq_dqblk {
> + unsigned int rq_bhardlimit; /* absolute limit on disk blks alloc */
> + unsigned int rq_bsoftlimit; /* preferred limit on disk blks */
> + unsigned int rq_curblocks; /* current block count */
> + unsigned int rq_fhardlimit; /* absolute limit on allocated files */
> + unsigned int rq_fsoftlimit; /* preferred file limit */
> + unsigned int rq_curfiles; /* current # allocated files */
> + unsigned int rq_btimeleft; /* time left for excessive disk use */
> + unsigned int rq_ftimeleft; /* time left for excessive files */
> +};
> +
> struct getquota_args {
> string gqa_pathp; /* path to filesystem of interest */
> - int gqa_uid;/* inquire about quota for uid */
> + int gqa_uid;/* Inquire about quota for uid */
> };
>
> +struct setquota_args {
> + int sqa_qcmd;
> + string sqa_pathp; /* path to filesystem of interest */
> + int sqa_id; /* Set quota for uid */
> + sq_dqblk sqa_dqblk;
> +};
> +
> +struct ext_getquota_args {
> + string gqa_pathp; /* path to filesystem of interest */
> + int gqa_type; /* Type of quota info is needed about */
> + int gqa_id; /* Inquire about quota for id */
> +};
> +
> +struct ext_setquota_args {
> + int sqa_qcmd;
> + string sqa_pathp; /* path to filesystem of interest */
> + int sqa_id; /* Set quota for id */
> + int sqa_type; /* Type of quota to set */
> + sq_dqblk sqa_dqblk;
> +};
> +
> /*
> * remote quota structure
> */
> @@ -37,7 +68,7 @@ struct rquota {
>
> enum gqr_status {
> Q_OK = 1, /* quota returned */
> - Q_NOQUOTA = 2, /* noquota for uid */
> + Q_NOQUOTA = 2, /* noquota for uid */
> Q_EPERM = 3 /* no permission to access
svn commit: r336022 - head/sys/dev/hwpmc
Author: mmacy
Date: Fri Jul 6 06:21:24 2018
New Revision: 336022
URL: https://svnweb.freebsd.org/changeset/base/336022
Log:
hwpmc: remove hacks to work around incorrect pc_domain
Modified:
head/sys/dev/hwpmc/hwpmc_logging.c
Modified: head/sys/dev/hwpmc/hwpmc_logging.c
==
--- head/sys/dev/hwpmc/hwpmc_logging.c Fri Jul 6 06:20:03 2018
(r336021)
+++ head/sys/dev/hwpmc/hwpmc_logging.c Fri Jul 6 06:21:24 2018
(r336022)
@@ -65,15 +65,7 @@ __FBSDID("$FreeBSD$");
#include
#endif
-#ifdef NUMA
-#define NDOMAINS vm_ndomains
#define curdomain PCPU_GET(domain)
-#else
-#define NDOMAINS 1
-#define curdomain 0
-#define malloc_domain(size, type, domain, flags) malloc((size), (type),
(flags))
-#define free_domain(addr, type) free(addr, type)
-#endif
/*
* Sysctl tunables
@@ -1261,7 +1253,7 @@ pmclog_initialize()
pmc_nlogbuffers_pcpu = PMC_NLOGBUFFERS_PCPU;
pmclog_buffer_size = PMC_LOG_BUFFER_SIZE;
}
- for (domain = 0; domain < NDOMAINS; domain++) {
+ for (domain = 0; domain < vm_ndomains; domain++) {
int ncpus = pmc_dom_hdrs[domain]->pdbh_ncpus;
int total = ncpus*pmc_nlogbuffers_pcpu;
@@ -1293,7 +1285,7 @@ pmclog_shutdown()
mtx_destroy(_kthread_mtx);
- for (domain = 0; domain < NDOMAINS; domain++) {
+ for (domain = 0; domain < vm_ndomains; domain++) {
while ((plb = TAILQ_FIRST(_dom_hdrs[domain]->pdbh_head)) !=
NULL) {
TAILQ_REMOVE(_dom_hdrs[domain]->pdbh_head, plb,
plb_next);
free(plb->plb_base, M_PMC);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336021 - in head/sys: kern sys
Author: mmacy
Date: Fri Jul 6 06:20:03 2018
New Revision: 336021
URL: https://svnweb.freebsd.org/changeset/base/336021
Log:
epoch(9): simplify initialization
replace manual NUMA aware allocation with a pcpu zone
Modified:
head/sys/kern/subr_epoch.c
head/sys/sys/epoch_private.h
Modified: head/sys/kern/subr_epoch.c
==
--- head/sys/kern/subr_epoch.c Fri Jul 6 02:06:03 2018(r336020)
+++ head/sys/kern/subr_epoch.c Fri Jul 6 06:20:03 2018(r336021)
@@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
@@ -93,29 +94,23 @@ TAILQ_HEAD (threadlist, thread);
CK_STACK_CONTAINER(struct ck_epoch_entry, stack_entry,
ck_epoch_entry_container)
- epoch_t allepochs[MAX_EPOCHS];
+epoch_tallepochs[MAX_EPOCHS];
DPCPU_DEFINE(struct grouptask, epoch_cb_task);
DPCPU_DEFINE(int, epoch_cb_count);
-static __read_mostly int domcount[MAXMEMDOM];
-static __read_mostly int domoffsets[MAXMEMDOM];
static __read_mostly int inited;
static __read_mostly int epoch_count;
__read_mostly epoch_t global_epoch;
__read_mostly epoch_t global_epoch_preempt;
static void epoch_call_task(void *context __unused);
+static uma_zone_t pcpu_zone_record;
-#if defined(__powerpc64__) || defined(__powerpc__) || !defined(NUMA)
-static bool usedomains = false;
-#else
-static bool usedomains = true;
-#endif
static void
epoch_init(void *arg __unused)
{
- int domain, cpu;
+ int cpu;
block_count = counter_u64_alloc(M_WAITOK);
migrate_count = counter_u64_alloc(M_WAITOK);
@@ -123,25 +118,9 @@ epoch_init(void *arg __unused)
switch_count = counter_u64_alloc(M_WAITOK);
epoch_call_count = counter_u64_alloc(M_WAITOK);
epoch_call_task_count = counter_u64_alloc(M_WAITOK);
- if (usedomains == false)
- goto done;
- domain = 0;
- domoffsets[0] = 0;
- for (domain = 0; domain < vm_ndomains; domain++) {
- domcount[domain] = CPU_COUNT(_domain[domain]);
- if (bootverbose)
- printf("domcount[%d] %d\n", domain, domcount[domain]);
- }
- for (domain = 1; domain < vm_ndomains; domain++)
- domoffsets[domain] = domoffsets[domain - 1] + domcount[domain -
1];
- for (domain = 0; domain < vm_ndomains; domain++) {
- if (domcount[domain] == 0) {
- usedomains = false;
- break;
- }
- }
-done:
+ pcpu_zone_record = uma_zcreate("epoch_record pcpu", sizeof(struct
epoch_record),
+ NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_PCPU);
CPU_FOREACH(cpu) {
GROUPTASK_INIT(DPCPU_ID_PTR(cpu, epoch_cb_task), 0,
epoch_call_task, NULL);
taskqgroup_attach_cpu(qgroup_softirq, DPCPU_ID_PTR(cpu,
epoch_cb_task), NULL, cpu, -1, "epoch call task");
@@ -161,39 +140,19 @@ epoch_init_smp(void *dummy __unused)
SYSINIT(epoch_smp, SI_SUB_SMP + 1, SI_ORDER_FIRST, epoch_init_smp, NULL);
#endif
-
static void
-epoch_init_numa(epoch_t epoch)
+epoch_ctor(epoch_t epoch)
{
- int domain, cpu_offset;
epoch_record_t er;
+ int cpu;
- for (domain = 0; domain < vm_ndomains; domain++) {
- er = malloc_domain(sizeof(*er) * domcount[domain], M_EPOCH,
- domain, M_ZERO | M_WAITOK);
- epoch->e_pcpu_dom[domain] = er;
- cpu_offset = domoffsets[domain];
- for (int i = 0; i < domcount[domain]; i++, er++) {
- epoch->e_pcpu[cpu_offset + i] = er;
- ck_epoch_register(>e_epoch, >er_record,
NULL);
- TAILQ_INIT((struct threadlist
*)(uintptr_t)>er_tdlist);
- er->er_cpuid = cpu_offset + i;
- }
- }
-}
-
-static void
-epoch_init_legacy(epoch_t epoch)
-{
- epoch_record_t er;
-
- er = malloc(sizeof(*er) * mp_ncpus, M_EPOCH, M_ZERO | M_WAITOK);
- epoch->e_pcpu_dom[0] = er;
- for (int i = 0; i < mp_ncpus; i++, er++) {
- epoch->e_pcpu[i] = er;
+ epoch->e_pcpu_record = uma_zalloc_pcpu(pcpu_zone_record, M_WAITOK);
+ CPU_FOREACH(cpu) {
+ er = zpcpu_get_cpu(epoch->e_pcpu_record, cpu);
+ bzero(er, sizeof(*er));
ck_epoch_register(>e_epoch, >er_record, NULL);
TAILQ_INIT((struct threadlist *)(uintptr_t)>er_tdlist);
- er->er_cpuid = i;
+ er->er_cpuid = cpu;
}
}
@@ -204,13 +163,9 @@ epoch_alloc(int flags)
if (__predict_false(!inited))
panic("%s called too early in boot", __func__);
- epoch = malloc(sizeof(struct epoch) + mp_ncpus * sizeof(void *),
- M_EPOCH, M_ZERO | M_WAITOK);
+ epoch = malloc(sizeof(struct epoch), M_EPOCH, M_ZERO | M_WAITOK);
Re: svn commit: r336019 - in head: . usr.sbin/config
On 7/5/18 6:53 PM, Kyle Evans wrote:
> On Thu, Jul 5, 2018 at 8:11 PM, Kyle Evans wrote:
>> Author: kevans
>> Date: Fri Jul 6 01:11:06 2018
>> New Revision: 336019
>> URL: https://svnweb.freebsd.org/changeset/base/336019
>>
>> Log:
>> config(8): De-dupe hint/env vars within a single file
>>
>> r335653 flipped the order in which hints/env files are concatenated to
>> match
>> the order in which vars are processed by the kernel. This is the other
>> hammer to drop.
>>
>> Use nv(9) to de-dupe entries within a single `hint` or `env` file, using
>> the
>> latest value specified for a key. This leaves some duplicates if a variable
>> is specified in multiple hint/env files or via `envvar` in a kernel config,
>> but the reversed order of concatenation (from r335653) makes this a
>> non-issue as the latest-specified version will be seen first.
>>
>> This change also silently rewrote hint bits to use the same sanitization
>> process that ian@ wrote for r335642. To the kernel, hints and env vars are
>> basically the same thing through early boot, then get merged into the
>> dynamic environment once kmem becomes available and the dynamic environment
>> is created. They should be subjected to the same restrictions.
>>
>> libnv has been added to -legacy for the time being to support the build of
>> config(8) with the new cnvlist API.
>>
>> Tested with: universe (11 host & 12 host)
>> MFC after:1 month
>>
>
> This seems to be causing pretty consistent config(8) failures on CI,
> kernels with neither hints nor environment variables, that neither of
> my universe builds nor any of my post-commit builds can reproduce. Can
> anyone else reproduce these failures that might be willing to give me
> a hint as to what kind of setup causes this?
>
> 01:47:58 cd /usr/src/sys/arm/conf;
> PATH=/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> config -d /usr/obj/usr/src/arm.armv7/sys/GENERIC -I
> '/usr/src/sys/arm/conf' '/usr/src/sys/arm/conf/GENERIC'
> 01:47:58 config: /usr/src/sys/arm/conf/GENERIC: No error: 0
>
I've seen this error with broken ABI. The -I${SRCTOP}/sys on the config
build may be contributing to the problem since sys/stat.h is ino64 and
the builder may not be. Really should not be bringing in the source
sys/ directory for any of the early host tool phases. There's some hack
patterns to bring in a limited amount of headers but in this case the
headers should be getting staged somewhere already.
Note legacy:
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${WORLDTMP}/legacy includes; \
So -IWORLDTMP/legacy/sys should find the nv headers. This is already
included via:
tools/build/mk/Makefile.boot:CFLAGS+= -I${WORLDTMP}/legacy/usr/include
Which is brought in for bootstrap-tools though via:
MAKEFLAGS="-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}"
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
