History log of /freebsd/sys/kern/kern_fork.c (Results 151 – 175 of 927)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 65dcb5bc 01-Oct-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r288197 through r288456.


# 5a2b666c 01-Oct-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 0f405ee7 28-Sep-2015 Navdeep Parhar <np@FreeBSD.org>

Sync up with head (up to r288341).


# 2f2f522b 28-Sep-2015 Andriy Gapon <avg@FreeBSD.org>

save some bytes by using more concise SDT_PROBE<n> instead of SDT_PROBE

SDT_PROBE requires 5 parameters whereas SDT_PROBE<n> requires n parameters
where n is typically smaller than 5.

Perhaps SDT_P

save some bytes by using more concise SDT_PROBE<n> instead of SDT_PROBE

SDT_PROBE requires 5 parameters whereas SDT_PROBE<n> requires n parameters
where n is typically smaller than 5.

Perhaps SDT_PROBE should be made a private implementation detail.

MFC after: 20 days

show more ...


# f94594b3 12-Sep-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Finish merging from head, messed up in previous attempt


# b5ff185e 12-Sep-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 23a32822 25-Aug-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from HEAD


# ab875b71 14-Aug-2015 Navdeep Parhar <np@FreeBSD.org>

Catch up with head, primarily for the 1.14.4.0 firmware.


# f98ee844 12-Aug-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r286422 through r286684.


Revision tags: release/10.2.0
# edc82223 10-Aug-2015 Konstantin Belousov <kib@FreeBSD.org>

Make kstack_pages a tunable on arm, x86, and powepc. On i386, the
initial thread stack is not adjusted by the tunable, the stack is
allocated too early to get access to the kernel environment. See
T

Make kstack_pages a tunable on arm, x86, and powepc. On i386, the
initial thread stack is not adjusted by the tunable, the stack is
allocated too early to get access to the kernel environment. See
TD0_KSTACK_PAGES for the thread0 stack sizing on i386.

The tunable was tested on x86 only. From the visual inspection, it
seems that it might work on arm and powerpc. The arm
USPACE_SVC_STACK_TOP and powerpc USPACE macros seems to be already
incorrect for the threads with non-default kstack size. I only
changed the macros to use variable instead of constant, since I cannot
test.

On arm64, mips and sparc64, some static data structures are sized by
KSTACK_PAGES, so the tunable is disabled.

Sponsored by: The FreeBSD Foundation
MFC after: 2 week

show more ...


# 1347814c 07-Aug-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r285924 through r286421.


# 6236e71b 31-Jul-2015 Ed Schouten <ed@FreeBSD.org>

Fix accidental line wrapping introduced in r286122.


# 367a13f9 31-Jul-2015 Ed Schouten <ed@FreeBSD.org>

Limit rights on process descriptors.

On CloudABI, the rights bits returned by cap_rights_get() match up with
the operations that you can actually perform on the file descriptor.

Limiting the rights

Limit rights on process descriptors.

On CloudABI, the rights bits returned by cap_rights_get() match up with
the operations that you can actually perform on the file descriptor.

Limiting the rights is good, because it makes it easier to get uniform
behaviour across different operating systems. If process descriptors on
FreeBSD would suddenly gain support for any new file operation, this
wouldn't become exposed to CloudABI processes without first extending
the rights.

Extend fork1() to gain a 'struct filecaps' argument that allows you to
construct process descriptors with custom rights. Use this in
cloudabi_sys_proc_fork() to limit the rights to just fstat() and
pdwait().

Obtained from: https://github.com/NuxiNL/freebsd

show more ...


# 8d0f1085 22-Jul-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r285341 through r285792.


# 6520495a 11-Jul-2015 Adrian Chadd <adrian@FreeBSD.org>

Add an initial NUMA affinity/policy configuration for threads and processes.

This is based on work done by jeff@ and jhb@, as well as the numa.diff
patch that has been circulating when someone asks

Add an initial NUMA affinity/policy configuration for threads and processes.

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

show more ...


# 416ba5c7 22-Jun-2015 Navdeep Parhar <np@FreeBSD.org>

Catch up with HEAD (r280229-r284686).


# 76aeda8a 20-Jun-2015 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r284188 through r284643.


# dad2fb7e 15-Jun-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# f6f6d240 10-Jun-2015 Mateusz Guzik <mjg@FreeBSD.org>

Implement lockless resource limits.

Use the same scheme implemented to manage credentials.

Code needing to look at process's credentials (as opposed to thred's) is
provided with *_proc variants of

Implement lockless resource limits.

Use the same scheme implemented to manage credentials.

Code needing to look at process's credentials (as opposed to thred's) is
provided with *_proc variants of relevant functions.

Places which possibly had to take the proc lock anyway still use the proc
pointer to access limits.

show more ...


# 4ea6a9a2 10-Jun-2015 Mateusz Guzik <mjg@FreeBSD.org>

Generalised support for copy-on-write structures shared by threads.

Thread credentials are maintained as follows: each thread has a pointer to
creds and a reference on them. The pointer is compared

Generalised support for copy-on-write structures shared by threads.

Thread credentials are maintained as follows: each thread has a pointer to
creds and a reference on them. The pointer is compared with proc's creds on
userspace<->kernel boundary and updated if needed.

This patch introduces a counter which can be compared instead, so that more
structures can use this scheme without adding more comparisons on the boundary.

show more ...


# 37a48d40 28-May-2015 Glen Barber <gjb@FreeBSD.org>

MFH: r282615-r283655

Sponsored by: The FreeBSD Foundation


# 98e0ffae 27-May-2015 Simon J. Gerraty <sjg@FreeBSD.org>

Merge sync of head


# 515b7a0b 26-May-2015 John Baldwin <jhb@FreeBSD.org>

Add KTR tracing for some MI ptrace events.

Differential Revision: https://reviews.freebsd.org/D2643
Reviewed by: kib


# 3deada41 08-May-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from HEAD


# edf1796d 06-May-2015 Mateusz Guzik <mjg@FreeBSD.org>

Fix up panics when fork fails due to hitting proc limit

The function clearning credentials on failure asserts the process is a
zombie, which is not true when fork fails.

Changing creds to NULL is u

Fix up panics when fork fails due to hitting proc limit

The function clearning credentials on failure asserts the process is a
zombie, which is not true when fork fails.

Changing creds to NULL is unnecessary, but is still being done for
consistency with other code.

Pointy hat: mjg
Reported by: pho

show more ...


12345678910>>...38