special case pi/4 <= |x| < 3*pi/4. This gives a tiny optimization (it
saves 2 subtractions, which are scheduled well so they take a whole 1
cycle extra on an AthlonXP), and simplifies the code so that the
following optimization is not so ugly.
Optimize for the range 3*pi/4 < |x| < 9*Pi/2 in the same way. On
Athlon{XP,64} systems, this gives a 25-40% optimization (depending a
lot on CFLAGS) for the cosf() and sinf() consumers on this range.
Relative to i387 hardware fcos and fsin, it makes the software versions
faster in most cases instead of slower in most cases. The relative
optimization is smaller for tanf() the inefficient part is elsewhere.
The 53-bit approximation to pi/2 is good enough for pi/4 <= |x| <
3*pi/4 because after losing up to 24 bits to subtraction, we still
have 29 bits of precision and only need 25 bits. Even with only 5
extra bits, it is possible to get perfectly rounded results starting
with the reduced x, since if x is nearly a multiple of pi/2 then x is
not near a half-way case and if x is not nearly a multiple of pi/2
then we don't lose many bits. With our intentionally imperfect rounding
we get the same results for cosf(), sinf() and tanf() as without this
optimization.
Move what can be moved (UMA zones creation, pv_entry_* initialization) from
pmap_init2() to pmap_init().
Create a new function, pmap_postinit(), called from cpu_startup(), to do the
L1 tables allocation.
pmap_init2() is now empty for arm as well.
standard in C99 and POSIX.1-2001+. They are also not deprecated, since
apart from being standard they can handle special args slightly better
than the ilogb() functions.
Move their documentation to ilogb.3. Try to use consistent and improved
wording for both sets of functions. All of ieee854, C99 and POSIX
have better wording and more details for special args.
Add history for the logb() functions and ilogbl(). Fix history for
ilogb().
this by accessing the cdev_priv element of the cdev structure. Looking
forward we need a better way to handle this, as this structure shouldn't
be frobbed by userspace.
Submitted by: Doug Steinwand
PR: bin/88203
MFC after: 1 week
Discussed with: phk
sio(4) will claim it. This change therefore only affects how ports
are handled when they are not claimed by sio(4), and in principle
will improve hardware support.
MFC after: 2 months
from there. All others get broken up and free'd individually to the mbuf
and cluster zones.
The packet zone is a secondary zone to the mbuf zone. There is currently
a limitation in UMA which prevents decreasing the packet zone stock when
the mbuf and cluster zone are drained and all their members are part of
packets. When this is fixed this change may be reverted.
- Fix a typo in rsmisc.c and a style change for consistency.
This patch will also appear in future ACPI-CA release.
Submitted by: Robert Moore <robert dot moore at intel dot com>
Tested by: ru
descriptor. This should fix the "memory modified after free" panics. This
patch will appear in a future acpi-ca distribution.
Submitted by: Robert Moore <robert.moore / intel.com>
Tested by: Peter Holm
Previously, pvzone's initialization was split between pmap_init() and
pmap_init2(). This split initialization was the underlying cause of
some UMA panics during initialization. Specifically, if the UMA boot
pages was exhausted before the pvzone was fully initialized, then UMA,
through no fault of its own, would use an inappropriate back-end
allocator leading to a panic. (Previously, as a workaround, we have
increased the UMA boot pages.) Fortunately, there is no longer any
reason that pvzone's initialization cannot be completed in
pmap_init().
Eliminate a check for whether pv_entry_high_water has been initialized
or not from get_pv_entry(). Since pvzone's initialization is
completed in pmap_init(), this check is no longer needed.
Use cnt.v_page_count, the actual count of available physical pages,
instead of vm_page_array_size to compute the maximum number of pv
entries.
Introduce the vm.pmap.pv_entries tunable on alpha and ia64.
Eliminate some unnecessary white space.
Discussed with: tegge (item #1)
Tested by: marcel (ia64)
a synchronous reprogramming of hardware MAC filters if the physical
interface are up and running. Previously, MAC filters would be
reconfigured only when the fec interface was brought up.
- Disallow bundle reconfiguration when virtual
interface is running; otherwise, removing a
port from a running configuration will cause
a panic in the start() method on the next packet
on an assumption that a bundle has an even
number of ports (2 or 4).
- Disallow bringing of virtual interface to a
running state when a bundle size is 0; otherwise,
adding and then removing the port will similarly
cause a panic.
- Add missing initialization of fec_ifstat when
adding a new port and fix media status reporting
when virtual interface isn't yet up (check for
fec_status of 1 rather than != 0).
previously, ifp->if_type was set to IFT_ETHER by
ether_ifattach(), now it's done by if_alloc() so
an assignment of if_type to IFT_PROPVIRTUAL after
if_alloc() but before ether_ifattach() broke it.
This makes arp(8) and friends happy about the fec
interfaces, and will allow us to use if_setlladdr()
on the fec interface.
- Set/reset IFF_DRV_RUNNING/IFF_DRV_OACTIVE in init()
and stop() methods rather than in ioctl(), like the
rest of the drivers do. This fixes a bug when an
"ifconfig fec0 ipv4_address" would not have made
the interface running, didn't launch the ticker
function to track media status of bundled ports,
etc.
used in the base system. This has been much discussed in the past
(typically people giving me a hard time for it). Since all that was
added to config was nocpu, and since we don't use it, we don't need to
bump the version.
current context in the IPI_STOP handler so that we can get accurate stack
traces of threads on other CPUs on these two archs like we do now on i386
and amd64.
Tested on: alpha, sparc64
the /etc/rc.d/pf script as it is implicitly added by /etc/rc.subr's
run_rc_command() because of the existing $pf_program.
Submitted by: Christoph Schug <chris@schug.net>
MFC after: 1 week
Reported by: scottl
I'm not very fond of using the non-standard lockf(1) here, but I
have no better idea at the moment. NetBSD uses ln(1) to create a
lock file, but this approach can result in a deadlock if make is
interrupted, leaving an orphaned lock file.
