Changed i586_ctr_bias from long long to u_int. Only the low 32 bits
are used now that microtime uses a multiplication to do the scaling.
Previously the high 32 bits had to match those of rdtsc() to prevent
overflow traps and invalid timeval adjustments.
block number.. (assuming Debugger() returned). The disk drivers assume
that dscheck() sets both error markers (bp->b_error and set B_ERROR in
bp->b_flags) if it fails.
does) before calling dscheck(). dscheck() doesn't appreciate this and
calls Debugger() and returns without setting bp->b_error.
This can happen when there is a casting error and offsets > 2G are
converted to negative off_t's in the disk tools. (dumpfs used to do this).
early enough when the dump device is specified in the config file.
Removed stale comment about configuration root and swap devices.
Don't bother clearing dumplo when dumpdev is set to NODEV. Everything
is controlled by dumpdev.
Fixed the kern.dumpdev sysctl. Writes were handle bogusly.
interfaces. This creates two new tables in the net.link.generic branch
of the MIB; one contains (essentially) `ifdata' structures, and the other
contains a blob provided by the interface (and presumably used to
implement link-layer-specific MIB variables). A number of things
have been moved around in the `ifnet' and `ifdata' structures, so
NEW VERSIONS OF ifconfig(8) AND routed(8) ARE REQUIRED. (A simple
recompile is all that's necessary.)
I have a sample program which uses this interface for those interested
in making use of it.
problem with the 'shell scripts' was found, but there was a 'strange'
problem found with a 486 laptop that we could not find. This commit
backs the code back to 25-jul, and will be re-entered after the snapshot
in smaller (more easily tested) chunks.
is little or no reason to create a swap pager for small mmap's. The
vm_map_insert code will automatically create a swap pager if the object
becomes too large. This fix, per a request from phk.
and then never accept for sending packet from upper layer anymore
(i.e. ping -f )
Reviewed by: David Greenman <dg@root.com>
Submitted by: amurai@spec.co.jp
performance issues.
1) The pmap module has had too many inlines, and so the
object file is simply bigger than it needs to be.
Some common code is also merged into subroutines.
2) Removal of some *evil* PHYS_TO_VM_PAGE macro calls.
Unfortunately, a few have needed to be added also.
The removal caused the need for more vm_page_lookups.
I added lookup hints to minimize the need for the
page table lookup operations.
3) Removal of some bogus performance improvements, that
mostly made the code more complex (tracking individual
page table page updates unnecessarily). Those improvements
actually hurt 386 processors perf (not that people who
worry about perf use 386 processors anymore :-)).
4) Changed pv queue manipulations/structures to be TAILQ's.
5) The pv queue code has had some performance problems since
day one. Some significant scalability issues are resolved
by threading the pv entries from the pmap AND the physical
address instead of just the physical address. This makes
certain pmap operations run much faster. This does
not affect most micro-benchmarks, but should help loaded system
performance *significantly*. DG helped and came up with most
of the solution for this one.
6) Most if not all pmap bit operations follow the pattern:
pmap_test_bit();
pmap_clear_bit();
That made for twice the necessary pv list traversal. The
pmap interface now supports only pmap_tc_bit type operations:
pmap_[test/clear]_modified, pmap_[test/clear]_referenced.
Additionally, the modified routine now takes a vm_page_t arg
instead of a phys address. This eliminates a PHYS_TO_VM_PAGE
operation.
7) Several rewrites of routines that contain redundant code to
use common routines, so that there is a greater likelihood of
keeping the cache footprint smaller.
blocked in a write() while waiting for the output to drain, sleep only
for tp->t_timeout, not forever. This only seems to happen when there is
either a modem lockup holding the hardware flow control down, or due to
some problem in the driver with processes attempting to write after the
modem has hung up (eg: elm, tf).
when attepmting to add certain types of routes. This problem
only manifested itself in the presence of unconfigured point-to-point
interfaces.
Noticed by: Chuck Cranor <chuck@maria.wustl.edu>
