If we load a binary that is designed to be a library, it produces
relocatable code via assembler directives in the assembly itself
(rather than compiler options). This emits R_X86_64_PLT32 relocations,
which are not handled by the kernel linker.
Submitted by: gallatin
Reviewed by: kib
conflict with the opensolaris kernel module.
This patch solves a problem where the kernel linker will incorrectly
resolve opensolaris kmem_xxx() functions as linuxkpi ones, which leads
to a panic when these functions are used.
Submitted by: gallatin @
Sponsored by: Mellanox Technologies
MFC after: 1 week
On pre-WS2016 Hyper-V, if the only LUNs > 7 are used, then all disks
fails to attach. Mainly because those versions of Hyper-V do not set
SRB_STATUS properly and deliver junky INQUERY responses.
Submitted by: Hongjiang Zhang <honzhan microsoft com>
Reported by: Hongxiong Xian <v-hoxian microsoft com>
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8724
server.
This patch uses the sysctl vfs.nfsd.server_min_nfsvers to determine
if/what versions of NFS service should be registered with rpcbind.
For NFSv4 only, it does not register at all, since NFSv4 always uses 2049
and does not require rpcbind.
For NFSv3 minimum, it registers NFSv3 but not NFSv2.
Tested by: jmader2@gmu.edu
Submitted by: jmader2@gmu.edu (earlier version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8696
Add some shortcuts in LazyValueInfo to reduce compile time of
Correlated Value Propagation.
The patch is to partially fix PR10584. Correlated Value Propagation
queries LVI to check non-null for pointer params of each callsite. If
we know the def of param is an alloca instruction, we know it is
non-null and can return early from LVI. Similarly, CVP queries LVI to
check whether pointer for each mem access is constant. If the def of
the pointer is an alloca instruction, we know it is not a constant
pointer. These shortcuts can reduce the cost of CVP significantly.
Differential Revision: https://reviews.llvm.org/D18066
This significantly reduces memory usage and compilation time when
compiling a particular C++ source file of the graphics/colmap port.
PR: 215136
MFC after: 3 days
Original commit "7090 zfs should improve allocation order" declares alloc
queue sorted by time and offset. But in practice io_offset is always zero,
so sorting happened only by time, while order of writes with equal time was
completely random. On Illumos this did not affected much thanks to using
high resolution timestamps. On FreeBSD due to using much faster but low
resolution timestamps it caused bad data placement on disks, affecting
further read performance.
This change switches zio_timestamp_compare() from comparing uninitialized
io_offset to really populated io_bookmark values. I haven't decided yet
what to do with timestampts, but on simple tests this change gives the
same peformance results by just making code to work as declared.
MFC after: 1 week
In particular, the fault access type is accounted for when the
aperture page is moved to GTT domain. On the other hand, the current
pager structure is left intact, most important, only one page is
instantiated per populate call.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
It allows to provide configurable agressive prefaulting and useful
hints to page daemon about memory allocations, on faults for pages
managed by phys pager. In fact, this implementation is superior to
the MAP_SHARED_PHYS hack from my Postgresql paper, while giving
similar benefits of reducing the page faults numbers on SysV shared
memory mappings.
Reviewed by: alc
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
with cdev_pg_populate() to provide device drivers access to it. It
gives drivers fine control of the pages ownership and allows drivers
to implement arbitrary prefault policies.
The populate method is called on a page fault and is supposed to
populate the vm object with the page at the fault location and some
amount of pages around it, at pager's discretion. VM provides the
pager with the hints about current range of the object mapping, to
avoid instantiation of immediately unused pages, if pager decides so.
Also, VM passes the fault type and map entry protection to the pager,
allowing it to force the optimal required ownership of the mapped
pages.
Installed pages must contiguously fill the returned region, be fully
valid and exclusively busied. Of course, the pages must be compatible
with the object' type.
After populate() successfully returned, VM fault handler installs as
many instantiated pages into the process page tables as it sees
reasonable, while still obeying the correct semantic for COW and vm
map locking.
The method is opt-in, pager sets OBJ_POPULATE flag to indicate that
the method can be called. If pager' vm objects can be shadowed, pager
must implement the traditional getpages() method in addition to the
populate(). Populate() might fall back to the getpages() on per-call
basis as well, by returning VM_PAGER_BAD error code.
For now for device pagers, the populate() method is only allowed to be
used by the managed device pagers, but the limitation is only made
because there is no unmanaged fault handlers which could use it right
now.
KPI designed together with, and reviewed by: alc
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
contain a vm_page_t at the specified index. However, with this
change, vm_radix_remove() no longer panics. Instead, it returns NULL
if there is no vm_page_t at the specified index. Otherwise, it
returns the vm_page_t. The motivation for this change is that it
simplifies the use of radix tries in the amd64, arm64, and i386 pmap
implementations. Instead of performing a lookup before every remove,
the pmap can simply perform the remove.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D8708
values. This more closely matches other wifi drivers in the tree.
The bitmap levels have been based closely on other drivers (primarily
[u]rtwn(4)) in the hope that one day these can be unified into a shared
wifi-debug framework.
This is the first step of several pieces of work I'm planning on doing
with the run(4) driver. I may well adjust and refine some of the debug
bitmaps at a later date.
Reviewed by: adrian, avos
Differential Revision: https://reviews.freebsd.org/D8704