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
field holding the threadid. This is more useful for libthr than
libpthread, but still quite useful in libpthread as it can be used to
process interlaced records from multiple threads over the course of a
system call.
Detect old ktr_buffer values using the heuristic "if it's negative,
then it must not be a valid threadid". This may leave something to be
desired.
MFC after: 1 month
Reviewed by: davidxu
This causes attempts to update a non-existent file to report
an actual error instead of triggering an assertion failure.
PR: bin/87911
Thanks to: roemer.ulrich
MFC after: 3 days
Note: This does not entirely fix bin/87911. I need to decide on
the "correct" response when someone tries to update a non-existent
archive file.
command is handled as a shell function. This avoids the following
peculiar behaviour when /usr/bin is on a case-insensitive filesystem:
# READ foo
(... long pause, depending upon the amount of swap space available ...)
sh: Resource temporarily unavailable.
Reported by: I can't remember; someone on IRC.
MFC after: 1 week
looked for in the system make file directory or in the specified
-m paths instead of always looking in the other -I and .PATH
specified paths. (Commit log shamelessly stolen from NetBSD.)
Reviewed by: yar
appear to be never called:
(1) If a function is never called according to its call count but it
must have been called because its child time is nonzero, then print
it in the flat profile. Previously, if its call count was zero
then we only printed it in the flat profile if its self time was
nonzero.
(2) If a function has a zero call count but has a nonzero self or child
time, then print its total self time in the self time per call
column as a percentage of the total (self + child) time. It is
not possible to print the times per call in this case because the
call count is zero. Previously, this was handled by leaving both
per-call columns blank. The self time is printed in another column
but there was no way to recover the total time.
(1) partially fixes the case of the "never called" function main() and
prepares for (2) to apply to main() and other functions. Profiling
of main() was lost in the conversion from a.out to ELF, so main()'s
call count has always been zero for many years; then in the common
case where main() is a tiny function, it gets no profiling ticks, so
main() was completely lost in the flat profile.
(2) improves mainly cases like kernel threads. Most kernel threads
appear to be never called because they are always started before
userland can run to turn on profiling. As for main(), the fact that
they are called is not very interesting and their callers are
uninteresting, but their relative self time is interesting since they
are long-running.
Almost always printing percentages in the per-call columns would be
more useful than almost always printing 0.0ms. 0.1ms is now a long
time, so only very large functions take that long per call. The accuracy
per call can approach 1-10 nsec provided programs are run for about
100000 times as long as is necessary to get this accuracy with high
resolution kernel profiling.
you want to see, e.g., sendmail arguments mail(1) will use.
-H is not an independent flag, it's a modifier. Also explicitly
say that -H will cause mail(1) to exit as soon as it prints the headers.
MFC after: 5 days
Add a flags argument to wait_for_lock so that O_NONBLOCK can be
passed to open if a user doesn't want the open to sleep until the
lock becomes available.
Submitted by: Amir Shalem (partially modified)
for mutual exclusion:
A brief description of the problem:
1) Proc A picks up non-blocking lock on file X
2) Proc B attempts to pickup lock, fails then waits
3) Proc C attempts to pickup lock, fails then waits
4) Proc A releases lock
5) Proc B acquires lock, release it to pickup a non-blocking version
6) Proc C acquires lock, release it to pickup a non-blocking version
7) Both process B and C race each other to pickup lock again
This occurs mainly because the processes do not keep the lock after they have
been waiting on it. They drop it, attempt to re-acquire it. (They use the wait
to notify when the lock has become available then race to pick it up). This
results in additional CPU utilization during the race, and can also result
in processes picking locks up out of order.
This change attempts to correct this problem by eliminating the test/acquire
race and having the operating system handle it.
Reported by: kris
Tested by: kris
MFC after: 1 week
Split commands into two groups: one with optional count and one with
required argument. Changed synopsis line accordingly.
Added some hopefully-helpful comments based on experiments, knowing
that not all hardware works the same.
PR: docs/84101
Approved by: keramida
MFC after: 3 days
replacement and has additional features which make it superior.
Discussed on: -arch
Reviewed by: thompsa
X-MFC-after: never (RELENG_6 as transition period)
