History log of /openbsd-src/sys/kern/subr_percpu.c (Results 1 – 11 of 11)
Revision Date Author Comments
# bf0d449c 16-Sep-2023 mpi <mpi@openbsd.org>

Allow counters_read(9) to take an optional scratch buffer.

Using a scratch buffer makes it possible to take a consistent snapshot of
per-CPU counters without having to allocate memory.

Makes ddb(4)

Allow counters_read(9) to take an optional scratch buffer.

Using a scratch buffer makes it possible to take a consistent snapshot of
per-CPU counters without having to allocate memory.

Makes ddb(4) show uvmexp command work in OOM situations.

ok kn@, mvs@, cheloha@

show more ...


# 8f25c57f 03-Oct-2022 bluhm <bluhm@openbsd.org>

Add a second membar producer into counters_zero(). Now it is
symmetric to counters_read().
OK jmatthew@


# 678831be 10-Mar-2021 jsg <jsg@openbsd.org>

spelling

ok gnezdo@ semarie@ mpi@


# b27348b2 08-Sep-2017 deraadt <deraadt@openbsd.org>

If you use sys/param.h, you don't need sys/types.h


# 599d0588 05-Feb-2017 jca <jca@openbsd.org>

Always allocate counters memory using type M_COUNTERS.

This makes the API simpler, and is probably more useful than spreading
counters memory other several types, making it harder to track.

Prodded

Always allocate counters memory using type M_COUNTERS.

This makes the API simpler, and is probably more useful than spreading
counters memory other several types, making it harder to track.

Prodded by mpi, ok mpi@ stsp@

show more ...


# e05abaed 11-Jan-2017 bluhm <bluhm@openbsd.org>

Move the membar in counters_read(). It has to be between reading
the generation number and the counters. In counters_zero() put a
membar after resetting the counters, but before writing the generat

Move the membar in counters_read(). It has to be between reading
the generation number and the counters. In counters_zero() put a
membar after resetting the counters, but before writing the generation
number.
OK mpi@ patrick@

show more ...


# 8457285f 27-Oct-2016 dlg <dlg@openbsd.org>

use ncpusfound to size the percpu allocations.

ncpus is used on half the architectures to indicate the number of
cpus that have been hatched, and is used on them in things like ddb
to figure out how

use ncpusfound to size the percpu allocations.

ncpus is used on half the architectures to indicate the number of
cpus that have been hatched, and is used on them in things like ddb
to figure out how many cpus to shut down again.

ncpusfound is incremented during autoconf on MP machines to show
how big ncpus will probably become. percpu is initted after autoconf
but before cpus are hatched, so this works well.

show more ...


# 780021b3 24-Oct-2016 dlg <dlg@openbsd.org>

avoid using realloc in the name of things that dont work like realloc.

cpumem_realloc and counters_realloc actually allocated new per cpu data
for new cpus, they didnt resize the existing allocation

avoid using realloc in the name of things that dont work like realloc.

cpumem_realloc and counters_realloc actually allocated new per cpu data
for new cpus, they didnt resize the existing allocation.

specifically, this renames cpumem_reallod to cpumem_malloc_ncpus, and
counters_realloc to counters_alloc_ncpus.

ok (and with some fixes by) bluhm@

show more ...


# 6c8f19e1 24-Oct-2016 deraadt <deraadt@openbsd.org>

non-MP vs MP codepaths were confusingly split between the .c and .h file.
Unify these by placing #ifdef MULTIPROCESSOR inside the functions, then
collapse further to reduce _KERNEL blocks
ok dlg


# 5cffaf98 21-Oct-2016 dlg <dlg@openbsd.org>

consistently zero the allocated memory in both the MP and UP cases.

from markus@


# 04e271af 21-Oct-2016 dlg <dlg@openbsd.org>

add generalised access to per cpu data structures and counters.

both the cpumem and counters api simply allocates memory for each cpu in
the system that can be used for arbitrary per cpu data (via c

add generalised access to per cpu data structures and counters.

both the cpumem and counters api simply allocates memory for each cpu in
the system that can be used for arbitrary per cpu data (via cpumem), or
a versioned set of counters per cpu (counters).

there is an alternate backend for uniprocessor systems that basically
turns the percpu data access into an immediate access to a single
allocation.

there is also support for percpu data structures that are available at
boot time by providing an allocation for the boot cpu. after autoconf,
these allocations have to be resized to provide for all cpus that were
enumerated by boot.

ok mpi@

show more ...