Revision tags: release/14.0.0 |
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0 |
|
#
78e3a168 |
| 19-Jul-2021 |
Mateusz Guzik <mjg@FreeBSD.org> |
arm: dedup counter(9) address calculation
Sponsored by: Rubicon Communications, LLC ("Netgate")
|
Revision tags: release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0 |
|
#
c5c3ba6b |
| 03-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r351317 through r351731.
|
#
a2a0f906 |
| 29-Aug-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
Centralize __pcpu definitions.
Many extern struct pcpu <something>__pcpu declarations were copied/pasted in sources. The issue is that the definition is MD, but it cannot be provided by machine/pcp
Centralize __pcpu definitions.
Many extern struct pcpu <something>__pcpu declarations were copied/pasted in sources. The issue is that the definition is MD, but it cannot be provided by machine/pcpu.h due to actual struct pcpu defined in sys/pcpu.h later than the inclusion of machine/pcpu.h. This forced the copying when other code needed direct access to __pcpu. There is no way around it, due to machine/pcpu.h supplying part of struct pcpu fields.
To work around the problem, add a new machine/pcpu_aux.h header, which should fill any needed MD definitions after struct pcpu definition is completed. This allows to remove copies of __pcpu spread around the source. Also on x86 it makes it possible to remove work arounds like OFFSETOF_CURTHREAD or clang specific warnings supressions.
Reported and tested by: lwhsu, bcran Reviewed by: imp, markj (previous version) Discussed with: jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D21418
show more ...
|
Revision tags: release/11.3.0, release/12.0.0 |
|
#
ab3059a8 |
| 06-Jul-2018 |
Matt Macy <mmacy@FreeBSD.org> |
Back pcpu zone with domain correct pages
- Change pcpu zone consumers to use a stride size of PAGE_SIZE. (defined as UMA_PCPU_ALLOC_SIZE to make future identification easier)
- Allocate page from
Back pcpu zone with domain correct pages
- Change pcpu zone consumers to use a stride size of PAGE_SIZE. (defined as UMA_PCPU_ALLOC_SIZE to make future identification easier)
- Allocate page from the correct domain for a given cpu.
- Don't initialize pc_domain to non-zero value if NUMA is not defined There are some misconceptions surrounding this field. It is the _VM_ NUMA domain and should only ever correspond to valid domain values as understood by the VM.
The former slab size of sizeof(struct pcpu) was somewhat arbitrary. The new value is PAGE_SIZE because that's the smallest granularity which the VM can allocate a slab for a given domain. If you have fewer than PAGE_SIZE/8 counters on your system there will be some memory wasted, but this is obviously something where you want the cache line to be coming from the correct domain.
Reviewed by: jeff Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D15933
show more ...
|
Revision tags: release/11.2.0 |
|
#
af3dc4a7 |
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/arm: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error
sys/arm: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
554491ff |
| 20-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r316992 through r317215.
|
#
83c9dea1 |
| 17-Apr-2017 |
Gleb Smirnoff <glebius@FreeBSD.org> |
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to c
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to counter(9). - Since some vmmeter stats may be touched at very early stages of boot, before we have set up UMA and we can do counter_u64_alloc(), provide an early counter mechanism: o Leave one spare uint64_t in struct pcpu, named pc_early_dummy_counter. o Point counter(9) fields of vmmeter to pcpu[0].pc_early_dummy_counter, so that at early stages of boot, before counters are allocated we already point to a counter that can be safely written to. o For sparc64 that required a whole dummy pcpu[MAXCPU] array.
Further related changes: - Don't include vmmeter.h into pcpu.h. - vm.stats.vm.v_swappgsout and vm.stats.vm.v_swappgsin changed to 64-bit, to match kernel representation. - struct vmmeter hidden under _KERNEL, and only vmstat(1) is an exclusion.
This is based on benno@'s 4-year old patch: https://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014471.html
Reviewed by: kib, gallatin, marius, lidl Differential Revision: https://reviews.freebsd.org/D10156
show more ...
|
#
67d955aa |
| 09-Apr-2017 |
Patrick Kelsey <pkelsey@FreeBSD.org> |
Corrected misspelled versions of rendezvous.
The MFC will include a compat definition of smp_no_rendevous_barrier() that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib MFC after: 1 week D
Corrected misspelled versions of rendezvous.
The MFC will include a compat definition of smp_no_rendevous_barrier() that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10313
show more ...
|
#
1a36faad |
| 11-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r313301 through r313643.
|
#
15df32b4 |
| 07-Feb-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r313360
|
#
3b7a388b |
| 06-Feb-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Update arm and arm64 counters MD bits.
On arm64 use atomics. Then, both arm and arm64 do not need a critical section around update. Replace all cpus loop by CPU_FOREACH(). This brings arm and arm6
Update arm and arm64 counters MD bits.
On arm64 use atomics. Then, both arm and arm64 do not need a critical section around update. Replace all cpus loop by CPU_FOREACH(). This brings arm and arm64 counter(9) implementation closer to current amd64, but being more RISC-y, arm* version cannot avoid atomics.
Reported by: Alexandre Martins <alexandre.martins@stormshield.eu> Reviewed by: andrew Tested by: Alexandre Martins, andrew Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
show more ...
|
Revision tags: release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0 |
|
#
9268022b |
| 19-Nov-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head@274682
|
Revision tags: release/10.1.0 |
|
#
246e7a2b |
| 02-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r269962
Submitted by: Anish Gupta (akgupt3@gmail.com)
|
#
1b833d53 |
| 13-Aug-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r269943.
|
#
eaa4e276 |
| 02-Aug-2014 |
Ian Lepore <ian@FreeBSD.org> |
Use atomic_load/store_64() in the arm implementation of counter(9), and remove the XXX comments about non-atomic access to the counters.
|
Revision tags: release/9.3.0, release/10.0.0 |
|
#
0bfd163f |
| 18-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r256722.
|
Revision tags: release/9.2.0 |
|
#
d1d01586 |
| 05-Sep-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head
|
#
40f65a4d |
| 07-Aug-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r254014
|
#
552311f4 |
| 17-Jul-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @253398
|
#
ceae90c2 |
| 05-Jul-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r252763
|
#
70a7dd5d |
| 01-Jul-2013 |
Konstantin Belousov <kib@FreeBSD.org> |
Fix issues with zeroing and fetching the counters, on x86 and ppc64. Issues were noted by Bruce Evans and are present on all architectures.
On i386, a counter fetch should use atomic read of 64bit v
Fix issues with zeroing and fetching the counters, on x86 and ppc64. Issues were noted by Bruce Evans and are present on all architectures.
On i386, a counter fetch should use atomic read of 64bit value, otherwise carry from the increment on other CPU could be lost for the given fetch, making error of 2^32. If 64bit read (cmpxchg8b) is not available on the machine, it cannot be SMP and it is enough to disable preemption around read to avoid the split read.
On x86 the counter increment is not atomic on purpose, which makes it possible for the store of the incremented result to override just zeroed per-cpu slot. The effect would be a counter going off by arbitrary value after zeroing. Perform the counter zeroing on the same processor which does the increments, making the operations mutually exclusive. On i386, same as for the fetching, if the cmpxchg8b is not available, machine is not SMP and we disable preemption for zeroing.
PowerPC64 is treated the same as amd64.
For other architectures, the changes made to allow the compilation to succeed, without fixing the issues with zeroing or fetching. It should be possible to handle them by using the 64bit loads and stores atomic WRT preemption (assuming the architectures also converted from using critical sections to proper asm). If architecture does not provide the facility, using global (spin) mutex would be non-optimal but working solution.
Noted by: bde Sponsored by: The FreeBSD Foundation
show more ...
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0 |
|
#
69e6d7b7 |
| 12-Apr-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
sync from head
|