| Age | Commit message (Collapse) | Author |
|---|
|
ok kettenis@
|
|
ok kettenis@
|
|
clockintr(9) is a machine-independent clock interrupt scheduler. It
emulates most of what the machine-dependent clock interrupt code is
doing on every platform. Every CPU has a work schedule based on the
system uptime clock. For now, every CPU has a hardclock(9) and a
statclock(). If schedhz is set, every CPU has a schedclock(), too.
This commit only contains the MI pieces. All code is conditionally
compiled with __HAVE_CLOCKINTR. This commit changes no behavior yet.
At a high level, clockintr(9) is configured and used as follows:
1. During boot, the primary CPU calls clockintr_init(9). Global state
is initialized.
2. Primary CPU calls clockintr_cpu_init(9). Local, per-CPU state is
initialized. An "intrclock" struct may be installed, too.
3. Secondary CPUs call clockintr_cpu_init(9) to initialize their
local state.
4. All CPUs repeatedly call clockintr_dispatch(9) from the MD clock
interrupt handler. The CPUs complete work and rearm their local
interrupt clock, if any, during the dispatch.
5. Repeat step (4) until the system shuts down, suspends, or hibernates.
6. During resume, the primary CPU calls inittodr(9) and advances the
system uptime.
7. Go to step (2). This time around, clockintr_cpu_init(9) also
advances the work schedule on the calling CPU to skip events that
expired during suspend. This prevents a "thundering herd" of
useless work during the first clock interrupt.
In the long term, we need an MI clock interrupt scheduler in order to
(1) provide control over the clock interrupt to MI subsystems like
timeout(9) and dt(4) to improve their accuracy, (2) provide drivers
like acpicpu(4) a means for slowing or stopping the clock interrupt on
idle CPUs to conserve power, and (3) reduce the amount of duplicated
code in the MD clock interrupt code.
Before we can do any of that, though, we need to switch every platform
over to using clockintr(9) and do some cleanup.
Prompted by "the vmm(4) time bug," among other problems, and a
discussion at a2k19 on the subject. Lots of design input from
kettenis@. Early versions reviewed by kettenis@ and mlarkin@.
Platform-specific help and testing from kettenis@, gkoehler@,
mlarkin@, miod@, aoyama@, visa@, and dv@. Babysitting and spiritual
guidance from mlarkin@ and kettenis@.
Link: https://marc.info/?l=openbsd-tech&m=166697497302283&w=2
ok kettenis@ mlarkin@
|
|
ok deraadt@
|
|
|
|
ok deraadt@
|
|
|
|
It makes uvm_swap_free() faster: extents have a cost of O(n*n) which doesn't
really scale with gigabytes of swap.
Based on initial work from mpi@
The blist implementation comes from DragonFlyBSD.
The diff adds also a ddb(4) 'show swap' command to show the blist and help
debugging, and fix some off-by-one in size printed during hibernate.
ok mpi@
|
|
version number issues close to release
|
|
If ddb.console is set and your serial console driver uses it, db_rint(),
lets you enter ddb(4) by typing the ESC D escape sequence. This is
useful for drivers like sfuart(4) where the hardware doesn't have a true
BREAK mechanism.
Suggested by miod@, ok kettenis@ miod@
|
|
kstat allows the kernel to expose arbitrary data for userland to
consume. currently this is used by some network card drivers to
expose hardware counters they provide, and a bit by the network
stack to show things like ifq counters.
ok bluhm@ deraadt@
|
|
just 2*NPROCESS rather than NPROCESS+8*MAXUSERS. Results in a slightly
higher maxthread value - the previous value was fairly likely to be
exceeded on a system running a couple of heavily threaded processes.
> previous new
> MAXUSERS NPROCESS maxthread (2*NPROCESS)
> 80 1310 1950 2620
> 64 1054 1566 2108
> 32 542 798 1084
ok kettenis@
|
|
|
|
|
|
|
|
|
|
Based on our existing RA module for 11n.
The main difference is in dealing with 11ac-specific ratesets.
Tx rate selection heuristics remain identical.
Only supports 80MHz channels, for now. 160MHz is left for future work.
ok sthen@
|
|
lm700x: az, rt
tc921x: sfr
pt2254a: sfr, sf2r
|
|
used by wdsc on sgi (removed in 2021)
ok krw@
|
|
|
|
|
|
|
|
the big change is removing the integration with and reliance on
bridge(4) for learning vxlan endpoints. we have the etherbridge
layer now (which is used by veb, nvgre, bpe, etc) so vxlan can
operate independently of bridge(4) (or any other driver) while still
dynamically learning about other endpoints.
vxlan now uses the udp socket upcall mechanism to receive packets.
this means it actually creates and binds udp sockets to use rather
adding code in the udp layer for stealing packets from the udp
layer.
i think it's also important to note that this adds loop prevention
to the code. this stops a vxlan interface being used to transmit a
packet that was encapsulated in itself.
i want to clear this out of my tree where it's been sitting for
nearly a year. noone seems too concerned with the change either
way.
ok claudio@
|
|
This splits out the MI sequencing, backing it with per-architecture helper
functions. Further steps will be neccesary because ACPI and MD are too
tightly coupled, but soon we'll be able to use this code for more architectures
(which depends on figuring out the lowest-level cpu sleeping method)
ok kettenis
|
|
OK deraadt@ phessler@
|
|
|
|
if it is supported. Remove it from the global GENERIC config.
OK visa@ claudio@
|
|
API implemented is a deadend.
OK akoshibe@ yasuoka@ deraadt@ kn@ patrick@ sthen@
|
|
|
|
|
|
|
|
ok deraadt@
|
|
|
|
this allows us to dynamically trace function boundaries with btrace by patching
prologues and epilogues with a breakpoint upon which the handler records the data,
sends it back to userland for btrace to consume.
currently it's hidden behind DDBPROF, and there is still a lot to cleanup and
improve, but basic scripts that observe return codes from a probed function
work.
from Tom Rollet, with various changes by me
feedback and ok mpi@
|
|
|
|
ok deraadt@ kettenis@
|
|
OK deraadt@
|
|
Support to skip frames is missing on arm64 and i386, but the stack
traces are useful anyway. sparc64 should work, but I could not
test it. Other architectures do not have stacktrace_save_at() and
dynamic tracer does not link.
from patrick@; OK semarie@
|
|
|
|
|
|
Keeping files in CVS HEAD for now until we are certain we're not going back.
ok deraadt@
|
|
Otherwise compiling a kernel witout any other wifi drivers fails.
OK patrick deraadt
|
|
ok deraadt@
|
|
|
|
OK deraadt@ mpi@
|
|
Written by Christian Ehrhardt and myself, based on ieee80211_mira.c
but with significant changes.
The main difference is that RA does not attempt to precisely measure
actual throughput but simply deducts a loss percentage from the
theoretical throughput which can be achieved by a given MCS.
Unlike MiRa, RA does not use timeouts to trigger probing.
Probing is triggered only by changes in measured throughput.
Unlike MiRA, RA doesn't care whether a frame was part of an A-MPDU.
RA simply collects statistics for individual subframes. This makes reporting
very easy for drivers and seems to work well enough in practice.
Another difference is that drivers can report multi-rate retries properly
via ieee80211_ra_add_stats_ht(mcs, total, fail) which can be called
several times before ieee80211_ra_choose() selects a new Tx rate.
There is no reason any issues could not be fixed in ieee8011_mira.c but
I felt it was a good moment to burn the house down and start over.
And since this code diverges from how MiRA is described in the research
paper applying the "MiRA" label becomes inappropriate.
|
|
apart from the semantic differences between bridge(4) and veb(4),
the only missing bits in veb(4) is the transparent ipsec interception
support, and spanning tree.
|
|
my intention is to replace bridge(4), but the way it works is
different enough from from bridge that a name change is justified
to distinguish them. it also makes it easier to commit it to the
tree and work on it in parallel to bridge, and allows a window of
migration.
the main difference between veb(4) and bridge(4) is how they use
interfaces as ports. veb takes over interfaces completely and only
uses them to receive and transmit ethernet packets. bridge also use
each interface as a port to the ethernet segment it's connected to,
but also tries to continue supporting the use of the interface as
a way to talk to the network stack on the local system. supporting
the use of interfaces for both external and local communication is
where most of my confusion with bridge comes from, both when i'm
trying to operate it and also understand the code. changing this
semantic is where most of the simplification in veb comes from
compared to bridge.
because veb takes over interfaces, the ethernet network set up on
a veb is isolated from the host network stack. by default veb does
not interact with pf or the ip (and mpls) stacks. to enable pf for
ip frames going over veb ports link1 on the veb interface must be
set. to have the stack interact with a veb network, vport interfaces
must be created and added as ports to a veb.
the vport interface driver is provided as part of veb, and is handled
specially by veb. veb usually prevents the use of ports by the stack
for sending an receiving packets, but that's why vports exist, so
veb has special handling for them.
veb already supports a lot of the other features that bridge has,
including bridge rules and protected domains, but i got tired of
working out of the tree and stopped implementing them. the main
outstanding features is better address table management, the
blocknonip flag on ports, transparent ipsec interception, and
spanning tree. i may not bother with spanning tree unless someone
tells me that they actually use it.
the core ethernet learning bridge functionality is provided by the
etherbridge code that was factored out of nvgre and bpe. veb is
already (a lot) faster than bridge, and is better prepared to operate
in parallel on multiple CPUs concurrently.
thanks to hrvoje popovski for testing some earlier versions of this.
discussed with many
ok patrick@ jmatthew@
|
|
the "ports" that nvgre provides to etherbridge are ip addresses
used in the underlay network.
ok patrick@ jmatthew@
|
|
it's pretty straightforward since etherbridge was mostly based on
this code in the first place. the etherbridge_ops that bpe provides
to etherbridge set entries up to point at mac addresses in the
underlay network.
ok patrick@ jmatthew@
|
