r312538 pfg Jan. 20, 2017, 3:56 p.m.
For consistency with the qualifiers added in r310977, define a new
qualifier _Null_unspecified which is also defined in clang 3.7+.

Add two new macros:
__NULLABILITY_PRAGMA_PUSH
__NULLABILITY_PRAGMA_POP

These are for use in headers when we want avoid noisy warnings if
some pointers are left without nullability annotations.

These are added with way ahead of their first use to teach the GCC
ports headers of their existance before their first use.
ViewVC
r312537 hselasky Jan. 20, 2017, 3:47 p.m.
MFC after:		1 week
Sponsored by:		Mellanox Technologies
ViewVC
r312536 hselasky Jan. 20, 2017, 3:45 p.m.
- Add new sysctl node to control the transmit packet bufring.

- Add optimised version of the transmit routine which output packets
directly to the DMA ring instead of using bufring in case the transmit
lock is congested. This can reduce the number of taskswitches which in
turn influence the overall system CPU usage, depending on the
workload.

- Add " TX" suffix to debug name for transmit mutexes to silence some
witness warnings about aquiring duplicate locks having same name.

MFC after:		1 week
Sponsored by:		Mellanox Technologies
Suggested by:		gallatin @
ViewVC
r312535 jpaetzel Jan. 20, 2017, 3:01 p.m.
6569 large file delete can starve out write ops

  illumos/illumos-gate@ff5177ee8bf9a355131ce2cc61ae2da6a5a6fdd6
  https://github.com/illumos/illumos-gate/commit/ff5177ee8bf9a355131ce2cc61ae2da6a5a6fdd6

  https://www.illumos.org/issues/6569
    The core issue I've found is that there is no throttle for how many
    deletes get assigned to one TXG. As a results when deleting large files
    we end up filling consecutive TXGs with deletes/frees, then write
    throttling other (more important) ops.

    There is an easy test case for this problem. Try deleting several
    large files (at least 1/2 TB) while you do write ops on the same
    pool. What we've seen is performance of these write ops (let's
    call it sideload I/O) would drop to zero.

    More specifically the problem is that dmu_free_long_range_impl()
    can/will fill up all of the dirty data in the pool "instantly",
    before many of the sideload ops can get in. So sideload
    performance will be impacted until all the files are freed.

    The solution we have tested at Nexenta (with positive results)
    creates a relatively simple throttle for how many "free" ops we let
    into one TXG.

    However this solution exposes other problems that should also be
    addressed. If we are to slow down freeing of data that means one
    has to wait even longer (assuming vnode ref count of 1) to get shell
    back after an rm or for NFS thread to finish the free-ing op.
    To avoid this the proposed solution is to call zfs_inactive() async
    for "large" files. Async freeing then begs for the reclaimed space
    to be accounted for in the zpool's "freeing" prop.

    The other issue with having a longer delete is the inability to
    export/unmount for a longer period of time. The proposed solution
    is to interrupt freeing of blocks when a fs is unmounted.

  Author: Alek Pinchuk <alek@nexenta.com>
  Reviewed by: Matt Ahrens <mahrens@delphix.com>
  Reviewed by: Sanjay Nadkarni <sanjay.nadkarni@nexenta.com>
  Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
  Approved by: Dan McDonald <danmcd@omniti.com>

Reviewed by:	avg
Differential Revision:	D9008
ViewVC
r312534 emaste Jan. 20, 2017, 2:59 p.m.
Sponsored by:	The FreeBSD Foundation
ViewVC
r312533 mav Jan. 20, 2017, 1:49 p.m.
MFC after:	1 week
ViewVC
r312532 avg Jan. 20, 2017, 1:39 p.m.
It's possible to get EFAULT when writing a segment backed by a file
if the segment extends beyond the file.
The core dump could still be useful if we skip the rest of the segment
and proceed to other segements.
The skipped segment (or a portion of it) will be zero-filled.

While there, use 'const' to signify that core_write() only reads the
buffer and use __DECONST before calling vn_rdwr_inchunks() because it
can be used for both reading and writing.

Before the change:
kernel: Failed to write core file for process mmap_trunc_core (error 14)
kernel: pid 77718 (mmap_trunc_core), uid 1001: exited on signal 6

After the change:
kernel: Failed to fully fault in a core file segment at VA 0x800645000 with size 0x4000 to be written at offset 0x29000 for process mmap_trunc_core
kernel: pid 4901 (mmap_trunc_core), uid 1001: exited on signal 6 (core dumped)

Reviewed by:	julian, kib
Obtained from:	Panzura (older version of the change)
MFC after:	5 days
Sponsored by:	Panzura
Differential Revision: https://reviews.freebsd.org/D9233
ViewVC
r312531 avg Jan. 20, 2017, 1:21 p.m.
The error is:
vmm_dev.c: In function 'alloc_memseg':
vmm_dev.c:261:11: error: null argument where non-null required (argument 1) [-Werror=nonnull]

Apparently, the gcc is unable to figure out that if a ternary operator
produced a non-NULL value once, then the operator with exactly the same
operands would produce the same value again.

MFC after:	1 week
ViewVC
r312528 hselasky Jan. 20, 2017, 12:02 p.m.
Add own state variable to track if a sendqueue is stopped or not.
This will prevent traffic from entering the sendqueue while it is
being destroyed.

Update drain function to wait for traffic to be transmitted before
returning when the link state is active.

Add extra checks in transmit path for stopped SQ's.

While at it:
- Use likely() for a mbuf pointer check.
- Remove redundant IFF_DRV_RUNNING check.

MFC after:		1 week
Sponsored by:		Mellanox Technologies
ViewVC
r312527 hselasky Jan. 20, 2017, 11:11 a.m.
moderation mode. The presence of this feature is indicated through the
firmware capabilities.

MFC after:		1 week
Sponsored by:		Mellanox Technologies
ViewVC
r312526 hselasky Jan. 20, 2017, 10:47 a.m.
for new features and commands.

MFC after:		1 week
Sponsored by:		Mellanox Technologies
ViewVC
r312523 ngie Jan. 20, 2017, 8 a.m.
The remaining functionality seems to be covered in one form or
another via the NetBSD ATF testcase.

MFC after:	3 weeks
Sponsored by:	Dell EMC Isilon
ViewVC
r312522 adrian Jan. 20, 2017, 7:43 a.m.
Tested:

* AR9380, STA mode
ViewVC
r312521 ngie Jan. 20, 2017, 7:11 a.m.
The symlink testcase is expected to fail, post-r312519 (the revert of
r312404); mark it so.

MFC after:	3 weeks
Sponsored by:	Dell EMC Isilon
ViewVC
r312520 ngie Jan. 20, 2017, 6:47 a.m.
suite as usr.bin/sed/sed_test

Don't expect :emptybackref to fail -- it succeeds on FreeBSD

MFC after:	3 weeks
Sponsored by:	Dell EMC Isilon
ViewVC