| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
GENERIC/for WITNESS users, make sure the sysctl to disable the behavior
is read-only and always enabled.
|
|
|
|
| |
Thanks to: Tim J Robbins
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the use of '=' in conditionals in the examples
by the more correct '=='.
Clarify the example explaining that .for expansion takes place before
.if handling by showing the correct code instead of saying 'the other
way around'. Change a variable name there so the example is more parseable
to the human reader.
PR: docs/65400
Submitted by: Roman Neuhauser <neuhauser@chello.cz>
|
| |
|
|
|
|
|
| |
PR: kern/67012
Submitted by: Zhenmin <zli4@cs.uiuc.edu>
|
| |
|
| |
|
|
|
|
| |
the time being.
|
| |
|
|
|
|
| |
not the link register, which was lucky enough to work.
|
| |
|
|
|
|
|
| |
section. Re-add a sentence from the BUGS section that went missing in
the previous commit.
|
| |
|
|
|
|
|
| |
the implementation of the -d option: we were skipping too many characters
when a non-alphanumeric character was encountered.
|
|
|
|
| |
been sorted with LC_COLLATE=C.
|
| |
|
| |
|
| |
|
|
|
|
| |
with "sh mkh" so it works if the script is not executable.
|
|
|
|
| |
of OANYOF sets for the moment.
|
| |
|
|
|
|
|
|
| |
to the ARM port. We set FLT_ROUNDS to -1 (indeterminate), because the
rounding mode on ARM is static, i.e. part of the FP instruction
format. Or at least that's my understanding.
|
|
|
|
| |
Approved by: julian (mentor)
|
|
|
|
| |
proper rounding mode as well.
|
| |
|
|
|
|
|
|
|
|
| |
- It was added to libc instead of libm. Hopefully no programs rely
on this mistake.
- It didn't work properly on large long doubles because its argument
was converted to type double, resulting in undefined behavior.
|
|
|
|
|
| |
-o offset - specifies where to start on the original provider
-s size - specifies size of the transparent provider
|
|
|
|
| |
KSE process-scope threads.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
improved chance of working despite pressure from running programs.
Instead of trying to throw a bunch of pages out to swap and hope for
the best, only a range that can potentially fulfill contigmalloc(9)'s
request will have its contents paged out (potentially, not forcibly)
at a time.
The new contigmalloc operation still operates in three passes, but it
could potentially be tuned to more or less. The first pass only looks
at pages in the cache and free pages, so they would be thrown out
without having to block. If this is not enough, the subsequent passes
page out any unwired memory. To combat memory pressure refragmenting
the section of memory being laundered, each page is removed from the
systems' free memory queue once it has been freed so that blocking
later doesn't cause the memory laundered so far to get reallocated.
The page-out operations are now blocking, as it would make little sense
to try to push out a page, then get its status immediately afterward
to remove it from the available free pages queue, if it's unlikely to
have been freed. Another change is that if KVA allocation fails, the
allocated memory segment will be freed and not leaked.
There is a sysctl/tunable, defaulting to on, which causes the old
contigmalloc() algorithm to be used. Nonetheless, I have been using
vm.old_contigmalloc=0 for over a month. It is safe to switch at
run-time to see the difference it makes.
A new interface has been used which does not require mapping the
allocated pages into KVA: vm_page.h functions vm_page_alloc_contig()
and vm_page_release_contig(). These are what vm.old_contigmalloc=0
uses internally, so the sysctl/tunable does not affect their operation.
When using the contigmalloc(9) and contigfree(9) interfaces, memory
is now tracked with malloc(9) stats. Several functions have been
exported from kern_malloc.c to allow other subsystems to use these
statistics, as well. This invalidates the BUGS section of the
contigmalloc(9) manpage.
|
|
|
|
| |
Tested by: marcel@
|
|
|
|
| |
variable and the default tape device.
|
|
|
|
| |
relocated to a better place, if one exists.)
|
|
|
|
| |
Noticed by: Suleiman Souhlal <refugee@segfaulted.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
specify "us" as the thread not the process/ksegrp/kse.
You can always find the others from the thread but the converse is not true.
Theorotically this would lead to runtime being allocated to the wrong
entity in some cases though it is not clear how often this actually happenned.
(would only affect threaded processes and would probably be pretty benign,
but it WAS a bug..)
Reviewed by: peter
|
|
|
|
| |
Missed by: scottl
|
| |
|
|
|
|
|
|
| |
is obviously not run a lot. (but is in some test cases).
This code is not usually run because it covers a case that doesn't
happen a lot (removing a node that has data traversing it).
|
| |
|
|
|
|
|
|
| |
where boot.config needs to reside. Also change /kernel
to /boot/loader, as that is the apparent default now. This
man page probably requires more updates.
|
|
|
|
| |
for subnormals with one implementation that works.
|
|
|
|
|
| |
reason being that pmap_pte_quick() requires the page queues lock, which is
already held, rather than Giant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
time now to break with the past: do not write the PID in the first note.
Rationale:
1. [impact of the breakage] Process IDs in core files serve no immediate
purpose to the debugger itself. They are only useful to relate a core
file to a process. This can provide context to the person looking at
the core file, provided one keeps track of this. Overall, not having
the PID in the core file is only in very rare occasions unfortunate.
2. [reason of the breakage] Having one PRSTATUS note contain the PID,
while all others contain the LWPID of the corresponding kernel thread
creates an irregularity for the debugger that cannot easily be worked
around. This is caused by libthread_db correlating user thread IDs to
kernel thread (aka LWP) IDs and thus aware of the actual LWPIDs.
Update comments accordingly.
|
|
|
|
|
|
|
|
|
|
|
| |
does not display the symptom). Evidently the ifpi2 controller needs to be
massaged more than it was.
Note that this does not close the PR since it was filed against 4.9.
MFC: 5 days
PR: kern/68756
Submitted by: Ari Suutari <ari.suutari@syncrontech.com>
|
| |
|
|
|
|
|
|
| |
headers from libpthread that are not WARNS=2 clean for -O2 builds.
Lower the WARNS level to 1. This is the highest level possible for
now.
|
|
|
|
|
|
|
|
|
| |
notably, this restores some of the contents in thread_db.h as well
as David Xu's copyright notice. This also fixes the includes in
the MD libpthread files which Scott tried to provide a quick fix
for.
Pointy hat: marcel
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that get certain types of control messages (ping6 and rtsol are
examples). This gets the new code closer to working:
1) Collect control mbufs for processing in the controlp ==
NULL case, so that they can be freed by externalize.
2) Loop over the list of control mbufs, as the externalize
function may not know how to deal with chains.
3) In the case where there is no externalize function,
remember to add the control mbuf to the controlp list so
that it will be returned.
4) After adding stuff to the controlp list, walk to the
end of the list of stuff that was added, incase we added
a chain.
This code can be further improved, but this is enough to get most
things working again.
Reviewed by: rwatson
|
|
|
|
|
|
|
|
| |
more professional. While here, write a few lines of explanatory
text to explain what its for.
Discussed with: rwatson
With hat: core
|
|
|
|
| |
name.
|