| created | 2019-04-20T18:30:24Z |
|---|---|
| begin | 2019-04-16T00:00:00Z |
| end | 2019-04-17T00:00:00Z |
| path | src/sys |
| commits | 8 |
| date | 2019-04-16T04:04:19Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if.c | log | diff | annotate |
| src/sys/net/if_var.h | log | diff | annotate | |
| src/sys/net/ifq.c | log | diff | annotate | |
| src/sys/net/ifq.h | log | diff | annotate | |
| message |
have another go at tx mitigation the idea is to call the hardware transmit routine less since in a lot of cases posting a producer ring update to the chip is (very) expensive. it's better to do it for several packets instead of each packet, hence calling this tx mitigation. this diff defers the call to the transmit routine to a network taskq, or until a backlog of packets has built up. dragonflybsd uses 16 as the size of it's backlog, so i'm copying them for now. i've tried this before, but previous versions caused deadlocks. i discovered that the deadlocks in the previous version was from ifq_barrier calling taskq_barrier against the nettq. interfaces generally hold NET_LOCK while calling ifq_barrier, but the tq might already be waiting for the lock we hold. this version just doesnt have ifq_barrier call taskq_barrier. it instead relies on the IFF_RUNNING flag and normal ifq serialiser barrier to guarantee the start routine wont be called when an interface is going down. the taskq_barrier is only used during interface destruction to make sure the task struct wont get used in the future, which is already done without the NET_LOCK being held. tx mitigation provides a nice performanace bump in some setups. up to 25% in some cases. tested by tb@ and hrvoje popovski (who's running this in production). ok visa@ |
|||
| date | 2019-04-16T09:40:21Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_myx.c | log | diff | annotate |
| message |
make sff page reads work on little endian archs too. like amd64. some modules seem to need more time when waiting for bytes while here. hrvoje popovski hit the endian issue |
|||
| date | 2019-04-16T11:42:56Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_myx.c | log | diff | annotate |
| message |
i2c reads are more reliable a byte at a time. reading all 256 at a time was a nice idea, but meant page 0xa2 wasnt appearing like it should. this follows what freebsd does more closely too. |
|||
| date | 2019-04-16T13:15:31Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/dev/simplebus.c | log | diff | annotate |
| src/sys/arch/arm64/dev/simplebusvar.h | log | diff | annotate | |
| message |
Prevent attaching drivers to devices for which we attached a driver early. ok patrick@, dlg@, visa@ |
|||
| date | 2019-04-16T13:15:32Z | |||
|---|---|---|---|---|
| author | yasuoka | |||
| files | src/sys/kern/uipc_socket2.c | log | diff | annotate |
| message |
Use the actual cluster size instead of fixed MCLBYTES for the condition in sb_compress(). Currently the actual cluster size might be 9KB even if the mtu is 1500, in this case a lot of memory space had been wasted, since sbcompress() doesn't compress because of previous condition. ok dlg claudio |
|||
| date | 2019-04-16T13:16:06Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm/simplebus/simplebus.c | log | diff | annotate |
| src/sys/arch/arm/simplebus/simplebusvar.h | log | diff | annotate | |
| message |
Prevent attaching drivers to devices for which we attached a driver early. ok patrick@, dlg@, visa@ |
|||
| date | 2019-04-16T14:32:44Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/arch/arm64/arm64/pmap.c | log | diff | annotate |
| message |
When entering kernel pages uncached we need to make sure to flush the caches. If the physical page was previously used by userland it is likely that this page is still in the cache and writing to the newly mapped page could result in unexpected behaviour. ok kettenis@ |
|||
| date | 2019-04-16T18:03:07Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/dev/pci/ppb.c | log | diff | annotate |
| message |
When we encounter ppb(4)s that are not configured we allocate a range of bus numbers from the parent's bus extent. On detach, which can happen with hotplug-able devices, we should free those busses. ok kettenis@ |
|||