summaryrefslogtreecommitdiffstats
path: root/sys/kern/init_sysent.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r318765:allanjude2017-06-111-2/+2
| | | | | | Allow cpuset_{get,set}affinity in capabilities mode Approved by: re (marius)
* MFC 313564:jhb2017-05-101-1/+0
| | | | | | | | | | | | | Drop the "created from" line from files generated by makesyscalls.sh. This information is less useful when the generated files are included in source control along with the source. If needed it can be reconstructed from the $FreeBSD$ tag in the generated file. Removing this information from the generated output permits committing the generated files along with the change to the system call master list without having inconsistent metadata in the generated files. Regenerate the affected files along with the MFC.
* MFC r315526vangyzen2017-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | Add clock_nanosleep() Add a clock_nanosleep() syscall, as specified by POSIX. Make nanosleep() a wrapper around it. Attach the clock_nanosleep test from NetBSD. Adjust it for the FreeBSD behavior of updating rmtp only when interrupted by a signal. I believe this to be POSIX-compliant, since POSIX mentions the rmtp parameter only in the paragraph about EINTR. This is also what Linux does. (NetBSD updates rmtp unconditionally.) Copy the whole nanosleep.2 man page from NetBSD because it is complete and closely resembles the POSIX description. Edit, polish, and reword it a bit, being sure to keep any relevant text from the FreeBSD page. Regenerate syscall files. Relnotes: yes Sponsored by: Dell EMC
* Regen after r313450.jhb2017-02-081-1/+1
|
* Regen after r305514, allow getdtablesize in capability modeemaste2016-09-071-1/+1
|
* Regenkib2016-08-291-1/+2
|
* Regenerate for r303857.bdrewery2016-08-081-1/+1
| | | | Approved by: re (gjb, implicit)
* Generate syscall tables and update pipe() implementation after r302094.brooks2016-06-221-2/+8
| | | | | | | | | | Mark the pipe() system call as COMPAT10. As of r302092 libc uses pipe2() with a zero flags value instead of pipe(). Approved by: re (gjb) Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D6816
* Regen.jhb2016-03-211-1/+1
|
* Regen.jhb2016-03-091-14/+14
|
* Missing regen after last change to sys/kern/syscalls.master.jhb2015-10-221-1/+1
|
* Add an initial NUMA affinity/policy configuration for threads and processes.adrian2015-07-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on work done by jeff@ and jhb@, as well as the numa.diff patch that has been circulating when someone asks for first-touch NUMA on -10 or -11. * Introduce a simple set of VM policy and iterator types. * tie the policy types into the vm_phys path for now, mirroring how the initial first-touch allocation work was enabled. * add syscalls to control changing thread and process defaults. * add a global NUMA VM domain policy. * implement a simple cascade policy order - if a thread policy exists, use it; if a process policy exists, use it; use the default policy. * processes inherit policies from their parent processes, threads inherit policies from their parent threads. * add a simple tool (numactl) to query and modify default thread/process policities. * add documentation for the new syscalls, for numa and for numactl. * re-enable first touch NUMA again by default, as now policies can be set in a variety of methods. This is only relevant for very specific workloads. This doesn't pretend to be a final NUMA solution. The previous defaults in -HEAD (with MAXMEMDOM set) can be achieved by 'sysctl vm.default_policy=rr'. This is only relevant if MAXMEMDOM is set to something other than 1. Ie, if you're using GENERIC or a modified kernel with non-NUMA, then this is a glorified no-op for you. Thank you to Norse Corp for giving me access to rather large (for FreeBSD!) NUMA machines in order to develop and verify this. Thank you to Dell for providing me with dual socket sandybridge and westmere v3 hardware to do NUMA development with. Thank you to Scott Long at Netflix for providing me with access to the two-socket, four-domain haswell v3 hardware. Thank you to Peter Holm for running the stress testing suite against the NUMA branch during various stages of development! Tested: * MIPS (regression testing; non-NUMA) * i386 (regression testing; non-NUMA GENERIC) * amd64 (regression testing; non-NUMA GENERIC) * westmere, 2 socket (thankyou norse!) * sandy bridge, 2 socket (thankyou dell!) * ivy bridge, 2 socket (thankyou norse!) * westmere-EX, 4 socket / 1TB RAM (thankyou norse!) * haswell, 2 socket (thankyou norse!) * haswell v3, 2 socket (thankyou dell) * haswell v3, 2x18 core (thankyou scott long / netflix!) * Peter Holm ran a stress test suite on this work and found one issue, but has not been able to verify it (it doesn't look NUMA related, and he only saw it once over many testing runs.) * I've tested bhyve instances running in fixed NUMA domains and cpusets; all seems to work correctly. Verified: * intel-pcm - pcm-numa.x and pcm-memory.x, whilst selecting different NUMA policies for processes under test. Review: This was reviewed through phabricator (https://reviews.freebsd.org/D2559) as well as privately and via emails to freebsd-arch@. The git history with specific attributes is available at https://github.com/erikarn/freebsd/ in the NUMA branch (https://github.com/erikarn/freebsd/compare/local/adrian_numa_policy). This has been reviewed by a number of people (stas, rpaulo, kib, ngie, wblock) but not achieved a clear consensus. My hope is that with further exposure and testing more functionality can be implemented and evaluated. Notes: * The VM doesn't handle unbalanced domains very well, and if you have an overly unbalanced memory setup whilst under high memory pressure, VM page allocation may fail leading to a kernel panic. This was a problem in the past, but it's much more easily triggered now with these tools. * This work only controls the path through vm_phys; it doesn't yet strongly/predictably affect contigmalloc, KVA placement, UMA, etc. So, driver placement of memory isn't really guaranteed in any way. That's next on my plate. Sponsored by: Norse Corp, Inc.; Dell
* Regen.kib2015-04-181-7/+13
|
* Run make sysent.jilles2015-01-231-1/+3
|
* Regen for r276654 (__getcwd()).dchagin2015-01-041-1/+1
|
* Regen for r274462.dchagin2014-11-131-1/+2
|
* Regenerate after r272823:marcel2014-10-091-5/+5
| | | | | | | | Move the SCTP syscalls to netinet with the rest of the SCTP code. Submitted by: Steve Kiernan <stevek@juniper.net> Reviewed by: tuexen, rrs Obtained from: Juniper Networks, Inc.
* Regen per r263318.attilio2014-03-181-3/+3
| | | | Sponsored by: EMC / Isilon storage division
* Allow sigwait(2) in capabilities mode.csjp2014-01-281-1/+1
| | | | | | | | | It's common for multi-threaded processes to create a thread for the purpose of synchronously processing signals. Allow such processes to utilize a capabilities sandbox. Discussed with: rwatson, pjd MFC after: 2 weeks
* Regenerate after r259438.pjd2013-12-151-16/+16
|
* Regenerate after r259436.pjd2013-12-151-1/+1
|
* Forgot to regenerate after r257736.pjd2013-12-151-1/+1
|
* Regen.jhb2013-09-191-1/+2
| | | | Approved by: re (delphij)
* Regen.jhb2013-09-121-1/+1
| | | | Approved by: re (kib)
* Regenerate after r255219.pjd2013-09-051-3/+3
| | | | Sponsored by: The FreeBSD Foundation
* aio_mlock() added:glebius2013-06-081-1/+2
| | | | | - Regen for r251526. - Bump __FreeBSD_version.
* Regenerate.kib2013-05-211-1/+1
|
* Regenerate files for pipe2().jilles2013-05-011-1/+2
|
* Regenerate files for accept4().jilles2013-05-011-1/+2
|
* Regen.mdf2013-04-021-1/+1
| | | | MFC after: 1 week
* Regenerate after r248599.pjd2013-03-211-1/+2
| | | | Sponsored by: The FreeBSD Foundation
* Regen after r247667.pjd2013-03-021-1/+3
|
* Regen after r247602.pjd2013-03-021-3/+8
|
* Regenerate after r243610.pjd2012-11-271-1/+1
|
* Regenkib2012-11-131-2/+3
|
* regen.davidxu2012-08-171-1/+1
|
* Implement syscall clock_getcpuclockid2, so we can get a clock iddavidxu2012-08-171-1/+1
| | | | | | | | for process, thread or others we want to support. Use the syscall to implement POSIX API clock_getcpuclock and pthread_getcpuclockid. PR: 168417
* Regenerate after r236361.pjd2012-05-311-5/+5
| | | | MFC after: 3 days
* Regenerate system call tables.ed2012-05-251-1/+1
|
* - Add the ffclock_getcounter(), ffclock_getestimate() and ffclock_setestimate()lstewart2011-11-211-3/+3
| | | | | | | | | | | | | | | | | | | | system calls to provide feed-forward clock management capabilities to userspace processes. ffclock_getcounter() returns the current value of the kernel's feed-forward clock counter. ffclock_getestimate() returns the current feed-forward clock parameter estimates and ffclock_setestimate() updates the feed-forward clock parameter estimates. - Document the syscalls in the ffclock.2 man page. - Regenerate the script-derived syscall related files. Committed on behalf of Julien Ridoux and Darryl Veitch from the University of Melbourne, Australia, as part of the FreeBSD Foundation funded "Feed-Forward Clock Synchronization Algorithms" project. For more information, see http://www.synclab.org/radclock/ Submitted by: Julien Ridoux (jridoux at unimelb edu au)
* Regenerate system call tables.ed2011-11-191-1/+1
|
* Regen.jhb2011-11-041-2/+2
|
* Auto-generated code from sys_ prefixing makesyscalls.sh changekmacy2011-09-161-323/+323
| | | | Approved by: re(bz)
* Auto-generated system call code based on r224987.jonathan2011-08-181-5/+5
| | | | Approved by: re (implicit)
* Regenerate system call files following r224812 changes to capabilities.conf.rwatson2011-08-131-12/+12
| | | | | | | | | | | A no-op for non-Capsicum kernels; for Capsicum kernels, completes the enabling of fooat(2) system calls using capabilities. With this change, and subject to bug fixes, Capsicum capability support is now complete for 9.0. Approved by: re (kib) Submitted by: jonathan Sponsored by: Google Inc
* Auto-generated system call code with cap_new(), cap_getrights().jonathan2011-07-151-2/+2
| | | | | Approved by: mentor (rwatson), re (Capsicum blanket) Sponsored by: Google Inc
* Regen.mdf2011-04-181-1/+3
|
* Regenerate.trasz2011-03-301-1/+6
|
* Regenerate.trasz2011-03-051-1/+3
|
* Regenerate system call files following addition of cap_enter(2),rwatson2011-03-011-206/+206
| | | | | | | | | | cap_getmode(2), and capabilities.conf. Reviewed by: anderson Discussed with: benl, kris, pjd Obtained from: Capsicum Project Sponsored by: Google, Inc. MFC after: 3 months
OpenPOWER on IntegriCloud