Revision tags: release/14.0.0, release/13.2.0 |
|
#
cbc32e4c |
| 15-Feb-2023 |
Dmitry Chagin <dchagin@FreeBSD.org> |
cpuset: Add compat shim to the sched_affinity functions
To allow to run a newer world on a pre-1400079 kernel a compat shims to the sched_affinity functions has beed added.
Reported by: antoine Te
cpuset: Add compat shim to the sched_affinity functions
To allow to run a newer world on a pre-1400079 kernel a compat shims to the sched_affinity functions has beed added.
Reported by: antoine Tested by: antoine Reviewed by: kib Differential revision: https://reviews.freebsd.org/D38555 MFC after: 3 days
show more ...
|
#
c21b080f |
| 29-Jan-2023 |
Dmitry Chagin <dchagin@FreeBSD.org> |
cpuset: Fix sched_[g|s]etaffinity() for better compatibility with Linux.
Under Linux to sched_[g|s]etaffinity() functions the value returned from a call to gettid(2) (thread id) can be passed in the
cpuset: Fix sched_[g|s]etaffinity() for better compatibility with Linux.
Under Linux to sched_[g|s]etaffinity() functions the value returned from a call to gettid(2) (thread id) can be passed in the argument pid. Specifying pid as 0 will set the attribute for the calling thread, and passing the value returned from a call to getpid(2) (process id) will set the attribute for the main thread of the thread group.
Native cpuset(2) family of system calls has "which" argument to determine how the value of id argument is interpreted, i.e., CPU_WHICH_TID is used to pass a thread id and CPU_WHICH_PID - to pass a process id.
For now native sched_[g|s]etaffinity() implementation is wrong as uses "which" CPU_WHICH_PID to pass both (process and thread id) to the kernel. To fix this adding a new "which" CPU_WHICH_TIDPID intended to handle both id's.
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D38209 MFC after: 1 week
show more ...
|
Revision tags: release/12.4.0, release/13.1.0 |
|
#
f35093f8 |
| 11-May-2022 |
Dmitry Chagin <dchagin@FreeBSD.org> |
Use Linux semantics for the thread affinity syscalls.
Linux has more tolerant checks of the user supplied cpuset_t's.
Minimum cpuset_t size that the Linux kernel permits in case of getaffinity() is
Use Linux semantics for the thread affinity syscalls.
Linux has more tolerant checks of the user supplied cpuset_t's.
Minimum cpuset_t size that the Linux kernel permits in case of getaffinity() is the maximum CPU id, present in the system / NBBY, the maximum size is not limited. For setaffinity(), Linux does not limit the size of the user-provided cpuset_t, internally using only the meaningful part of the set, where the upper bound is the maximum CPU id, present in the system, no larger than the size of the kernel cpuset_t. Unlike FreeBSD, Linux ignores high bits if set in the setaffinity(), so clear it in the sched_setaffinity() and Linuxulator itself.
Reviewed by: Pau Amma (man pages) In collaboration with: jhb Differential revision: https://reviews.freebsd.org/D34849 MFC after: 2 weeks
show more ...
|
#
67fc9502 |
| 25-Apr-2022 |
Konstantin Belousov <kib@FreeBSD.org> |
sched_getaffinity(3): more compatibility with Linux
Report EINVAL instead of EDEADLK when impossible cpu mask is set.
Noted by: dchagin Reviewed by: dchagin (previous version), markj Sponsored by:
sched_getaffinity(3): more compatibility with Linux
Report EINVAL instead of EDEADLK when impossible cpu mask is set.
Noted by: dchagin Reviewed by: dchagin (previous version), markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D35045
show more ...
|
#
d9cacbf4 |
| 02-Jan-2022 |
Konstantin Belousov <kib@FreeBSD.org> |
sched_get/setaffinity(): try to be more compatible with Linux
in handling the cpuset sizes different from sizeof(cpuset_t).
For both cases, cpuset size shorter than sizeof(cpuset_t) results in EINV
sched_get/setaffinity(): try to be more compatible with Linux
in handling the cpuset sizes different from sizeof(cpuset_t).
For both cases, cpuset size shorter than sizeof(cpuset_t) results in EINVAL on Linux.
For sched_getaffinity(), be more permissive and accept cpuset size larger than our cpuset_t, by clipping the syscall argument and zeroing the rest of the output buffer. For sched_setaffinity(), we should allow shorter cpusets than current ABI size, again zeroing the rest of the bits.
With this change, python os.sched_get/setaffinity functions work.
Reported by: se Sponsored by: The FreeBSD Foundation MFC after: 1 week
show more ...
|
#
e2650af1 |
| 30-Dec-2021 |
Stefan Eßer <se@FreeBSD.org> |
Make CPU_SET macros compliant with other implementations
The introduction of <sched.h> improved compatibility with some 3rd party software, but caused the configure scripts of some ports to assume t
Make CPU_SET macros compliant with other implementations
The introduction of <sched.h> improved compatibility with some 3rd party software, but caused the configure scripts of some ports to assume that they were run in a GLIBC compatible environment.
Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being added to ports, but there still were compatibility issues due to invalid assumptions made in autoconfigure scripts.
The differences between the FreeBSD version of macros like CPU_AND, CPU_OR, etc. and the GLIBC versions was in the number of arguments: FreeBSD used a 2-address scheme (one source argument is also used as the destination of the operation), while GLIBC uses a 3-adderess scheme (2 source operands and a separately passed destination).
The GLIBC scheme provides a super-set of the functionality of the FreeBSD macros, since it does not prevent passing the same variable as source and destination arguments. In code that wanted to preserve both source arguments, the FreeBSD macros required a temporary copy of one of the source arguments.
This patch set allows to unconditionally provide functions and macros expected by 3rd party software written for GLIBC based systems, but breaks builds of externally maintained sources that use any of the following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.
One contributed driver (contrib/ofed/libmlx5) has been patched to support both the old and the new CPU_OR signatures. If this commit is merged to -STABLE, the version test will have to be extended to cover more ranges.
Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do no longer require that option.
The FreeBSD version has been bumped to 1400046 to reflect this incompatible change.
Reviewed by: kib MFC after: 2 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D33451
show more ...
|
#
caacda7a |
| 17-Dec-2021 |
Math Ieu <sigsys@gmail.com> |
sched_get/setaffinity(3): pid 0 should designate current process
while FreeBSD' native sched_get/setaffinity use pid -1 for this.
PR: 260487 MFC after: 1 week
|
Revision tags: release/12.3.0 |
|
#
90fa9705 |
| 11-Nov-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
sched.h: Hide all Linux compat sched_* functions under _WITH_CPU_SET_T
Instead of only hiding cpu_set_t compat typedef itself.
Too many software packages assume that sched_getaffinity() presence im
sched.h: Hide all Linux compat sched_* functions under _WITH_CPU_SET_T
Instead of only hiding cpu_set_t compat typedef itself.
Too many software packages assume that sched_getaffinity() presence implies full source compatibility with glibc. We can (and should) handle missing CPU_* macros, but then there are incompatible BIT_* uses which cannot be fixed in src/.
So hide everything under _WITH_CPU_SET_T, in particular, do not expose sched_getcpu(), sched_get/setaffinity(), as well as CPU_* and BIT_* macros. Consumers that want sched* functions must opt-in.
Reported by: portmgr (antoine) Sponsored by: The FreeBSD Foundation MFC after: 1 week
show more ...
|
#
43736b71 |
| 22-Oct-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
Add sched_get/setaffinity(3)
for compatibility with Linux.
Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32901
|