than that of the current thread has been woken up. I didn't see the
reason why the thread should otherwise relinquish the rest of its
quantum. I noticed for instance that client and app server window
threads were ping-ponging more than seemed necessary. In most cases
when the client sent a port message it would be unscheduled although it
had run only for a few microseconds and had still stuff to do.
I measured a relatively Terminal-heavy "find /boot" (second run), which
does now take 5-10% less time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27314 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Scheduling analysis output:
- Sort the threads by total run time.
- Group the locking primitives a thread has waited on by common type
and name. E.g. all "I/O request finished" condition variables are
put in a single group. The sum wait time and wait count is printed
for the group, so it is easy to see how often and how long the
thread had waited for I/O.
- Both the groups and their elements are sorted by wait time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27313 a95241bf-73f2-0310-859d-f6bbb57e9c96
* check if the device is still opened when waiting for data
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27310 a95241bf-73f2-0310-859d-f6bbb57e9c96
on Stop(), close the device, then wait for our service thread to quit
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27309 a95241bf-73f2-0310-859d-f6bbb57e9c96
gather additional information on the threads that were running and
what they were doing.
* Added "-o <output>" option for specifying a file to which to print the
statistics to.
* Some beautifications (usage, help, etc.).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27306 a95241bf-73f2-0310-859d-f6bbb57e9c96
unscheduled was incorrect.
* Introduced _kern_analyze_scheduling() syscall. It requires scheduler
kernel tracing to be enabled. It uses the tracing entries for a given
period of time to do a similar analysis the "scheduler" debugger
command does (i.e. number of runs, run time, latencies, preemption
times) for each thread. Additionally the analysis includes for each
thread how long the thread waited on each locking primitive in total.
* Added kernel tracing for the creation of semaphores and initialization
of condition variables, mutexes, and rw locks. The enabling macro is
SCHEDULING_ANALYSIS_TRACING. The only purpose is to provide
_kern_analyze_scheduling() with more info on the locking primitives
(the name in particular).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27304 a95241bf-73f2-0310-859d-f6bbb57e9c96
tracing buffer entries even when not in the kernel debugger.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27302 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The "Most influential developers" list wasn't such a good idea after all.
* Now we have "Current Maintainers" and "Past Maintainers". Some developers
who still have commit access are in the Past Maintainers list, since they
have not done a commit in a long time (more than a year at least)
* TODO: Move more people from Contributors into Past Maintainers, I don't
know many names and have not tried to match names to SVN commit log nick
names.
* Added Ralf Schuelke to the Contributors for his Pairs game contribution.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27299 a95241bf-73f2-0310-859d-f6bbb57e9c96
ioctl() prototype. Apparently some Linuxes discarded the <stropts.h>
header which POSIX demands.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27293 a95241bf-73f2-0310-859d-f6bbb57e9c96
this was most noticable in Deskbar when opening DataTranslations in Expand App Mode
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27291 a95241bf-73f2-0310-859d-f6bbb57e9c96
http://www.SpringDaemons.com/stas/if_ae-1214569185.tar.bz2
(This is the wired NIC on the Asus EEE PC!)
NOTE: It is not in the image because it currently still crashes, will look into that soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27290 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Delete longClickMessageRunner after its message arrived, to shorten its lifetime.
* Moved creation and deletion of longClickMessageRunner into methods.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27288 a95241bf-73f2-0310-859d-f6bbb57e9c96
fine, at least in the context of the layout management. I am investigating
a bug though that shows at least in WonderBrush (missing Filter menu).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27284 a95241bf-73f2-0310-859d-f6bbb57e9c96
developers was based on the oloh results, but these go only 3 years back. The
SVN revision history is much more complete and contains also the CVS history
apart from a screw up at revision 10. However, I was able to obtain a much
more correct list now and so some resorting was due. According to these stats,
Michael Lotz would not appear in the list - however, I feel he should be
in there, since he was the first to run Haiku with app_server, the first to
run a browser on it, wrote the USB stack and so on. The other possiblity would
be to make the cut at 7 entries, which coincidentally would mean everyone in the
list has contributed more than 1000 commits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27279 a95241bf-73f2-0310-859d-f6bbb57e9c96
the ipc hash table lock along with the semaphore set hash table lock were
hold, thinking (wrongly) that the semaphore set lock itself was not needed.
What could happen was that another process on semop could have gained the lock
of the set itself, and then release the semaphore set hash table lock.
This would make it think that the set was still valid, while it could have
actually been deleted right after it release the semaphore set hash table lock.
Same would have happened for any other processes waiting on the semaphore set
mutex queue. By calling the lock on the mutex when deleting the set, it
*should be* safe to assume that there is no one else waiting on its queue,
since the list of waiters is handled in a FIFO way.
As far as I can see from the mutex_destroy code, it looks safe to hold the lock
when calling this function. Please confirm.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27268 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stefano Ceccherini