In anticipation of doing some work on performance issues, I've been
experimenting with our kernel profiler the last few days. For those who
don't know, you can activate the profiler by including the /PROFILE option
on the command line. On each timer interrupt the current EIP will be saved,
after 30 sec a background task will convert the saved EIPs to function
name/file name, count how often each function name occurs and write the
results to a file %system_root%\profiler.log. There are 100 timer ticks per
second, a 30 sec measuring interval will therefore generate 3000 EIPs.
This works very nice, but I'm running into one problem on my 300MHz test
machine: conversion of the EIPs to function name by the background thread
takes about 60 sec. Almost all of that time is spent looking up the correct
.stabs entry from the info in the .sym file. This is done using a linear
search. Since there can be 100000 .stabs entries in a .sym file, going
through these for each of the 3000 measurements can mean 300000000 compares.
Even worse, two passes are made through the .stabs list for each
measurement, one to find the function name and one to find the file name. No
wonder this takes 60 sec.
So, we need to improve the search. I've done some simulations, and when I
use a binary search instead of a linear search, the performance is
dramatically better. Time required to convert all measurements drops from 60
sec to 0.06 sec, a 1000 fold improvement.
To be able to use a binary search, the information in the .sym file needs to
be sorted and uniform (each element contains the same type of data) which it
currently isn't. We have .stabs entries defining a function (N_FUN), source
line (N_SLINE) and source file (N_SO). Currently, we only use the .sym files
to convert an address to function name/file name/source line, not the other
way around (no function name to address for example). I'd like to drop using
the .stab format in the .sym files and change to the following format:
+----------+
|header |
+----------+
|symentries|
+----------+
|strings |
+----------+
The header would just contain the start location and number of symentries
plus start location and total size of the strings. Each symentry would have
the following info:
typedef struct tagSYM_ENTRY {
ULONG_PTR Address;
ULONG FunctionOffset;
ULONG FileOffset;
ULONG SourceLine;
} SYM_ENTRY, *PSYM_ENTRY;
where Address is an address relative to the beginning of the module,
FunctionOffset and FileOffset are offsets from the beginning of the strings
section and SourceLine contains the source line number. The symentries are
sorted by Address (done by rsym). Each Address would only appear once, and
information would be made as complete as possible (e.g. when creating the
symentries from the .stabs in the .nostrip.exe file each FunctionOffset
would be set to point to the function name from the most recently
encountered N_FUN .stab). This will allow us to retrieve all 3 pieces of
information (function name, file name and source line) by doing just a
single binary search.
Comments, thoughts, objections?
Gé van Geldorp.
It works here, computer is put into low power state everytime you click on
logoff.
Usurp (aka
Sylvain PETREOLLE)
Service de Production & d'Exploitation Informatique
GEFCO - #DMIT/DATO/PSI/PEI
Mail : <mailto:exploit@gefco.fr>
Tel : 01.49.05.29.29
-----Message d'origine-----
De : Gge [mailto:gerard.gatineau@laposte.net]
Envoyé : vendredi 28 janvier 2005 07:59
À : ReactOS Development List
Objet : [ros-dev] ACPI status
I built Ros with ACPI=1 but the feature is not working (in real
hardware) as the computer does not go into low power state .
At boot the debug messages displayed are :
DriverBase for acpi.sys : 9ce1300
Advanced Configuration and Power Interface Bus Driver
ACPI: System firmware supports:
+------------------------------------------------------------
| Sx states: +S0 +S1 -S2 -S3 +S4 +S5
+------------------------------------------------------------
What is the status of the ACPI feature ? Is it supported actually ?
Best regards
Gerard
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
----------------------------------------------------------------------------
Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels
et sont exclusivement destinés à l'usage de la personne à laquelle ils sont
adressés. Tout point de vue ou toute opinion contenus dans ce message
expriment la pensée personnelle de leur auteur et ne représentent pas
nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas
la personne à laquelle ce message est destiné, veuillez noter que vous avez
reçu cet e-mail par erreur et qu'il vous est strictement interdit
d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message.
Si vous avez reçu ce message par erreur, merci de contacter la personne qui
vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO
déclinent toute responsabilité en cas d'altération, de modification,
d'édition, de diffusion sans autorisation de ce message ou en cas
d'affection de ce message par un virus.
This message and any attachments (the "message") are confidential and
intended solely for the use of the individual to whom they are addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the GEFCO Group of Companies. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing, or copying of
this message is strictly prohibited. If you have received this message in
error please contact the sender and delete the message immediately. The
GEFCO Group of Companies shall not be liable for the message if altered,
changed, falsified, edited, diffused without authorization or affected by
any virus.
----------------------------------------------------------------------------
navaraf(a)svn.reactos.com wrote:
>Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497.
>
>
>Updated files:
>trunk/reactos/lib/kjs/makefile
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
Aren't you forcing non-inlining of EVERY function by doing this? Isn't
it better to enable the special no ctype inline macro?
Best regards,
Alex Ionescu
Hi Gunnar:
Great! less duplicated code == better code
I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now.
Best Regards
Waldo Alvarez
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Gunnar Dalsnes
Sent: Wed 1/26/2005 8:19 PM
To: ReactOS Development List
Subject: [ros-dev] msvcrt/crtdll "merge"
Hi,
I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into
a library lib\crt and have msvcrt and crtdll link against it. Only
dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be
dropped. It all seems to work nicely. One problem thou: I ran into some
header problems, where i relied on some stuff in include\msvcrt\string.h
but no matter what, mingw\include\string.h were included instead (and
they both defined _STRING_H_). After looking at the headers in
inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know
why they were put in include\msvcrt when mingw has headers for all of
this stuff? Can i just remove them (include\msvcrt)?
I looked at many depends files and saw most files depend on many mingw
headers. Is this correct? Should we depend on mingw headers at all?
Gunnar
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Dear ReactOS enthusiasts and friends,
We are currently in dire need of motivated people to help us build the
future OS of the masses. While our developers are busily creating new
code and fixing bugs, there remain dozens, if not more, of things to
take care of in our tree and in our code. I would like to extend an open
invitation to anyone interested on becoming a JANITOR (Just A Newbie
Intensively Training On ReactOS).
As a JANITOR, you will join a team of people, which, just like you, want
to see ReactOS succeed and have some spare time to help. You do NOT need
any coding experience! Most of the time, only simple word processing
skills are needed. Janitorial jobs will include cleaning up comment
headers, standardizing the debug system, alphabetizing code and
organizing files, compiling a list of fixmes, checking for spelling
mistakes, etc. These jobs will be custom tailored to your abilities, and
there will be no time limits (but you must commit to doing the job).
Also, JANITORs will have access to an online collaboration site where
the current top-priority jobs are presented, and where they can commit
to one of them. You can also share the workload and work in teams, or
however you work best. A status system will be available to monitor the
progression of jobs, and many more tools will become available.
So don't delay, and join the JANITOR program today! Send me an e-mail at
alex(a)relsoft.net with your name, e-mail and contact availabily (MSN,
ICQ, IRC (preferred)). A real-time communication tool will be preferred,
but I can acustom to people demanding exclusively e-mail contact (since
the JANITOR Project Site will have most of the information).
I know that many of you want to help but that the current state of the
outdatedness of the website and documentation, as well as the general
lack of directions are discouraging you. This will be a unique
experience to leave your mark in ReactOS.
Best regards,
Alex Ionescu
ReactOS JANITOR Program Manager
NOTE to Devs: The JANITOR Program is fully the child of my brain and is
a personal project, and will not use the ReactOS bandwidth, site, or
other resources unless explicit permission and agreement is made by all
developers. You will not need to do any additional task or handle
anything more and this will not affect your workload in any way.
Hello,
weiden(a)svn.reactos.com wrote:
> 1. fixed InbvPutPixels() to save the ebx register which caused bootvid
> to crash when built with optimizations
You need to save the esi register too.
ebx, esi, edi, and ebp are callee-saved registers in win32/x86.
VC++ and gcc expect external functions not to modify these registers.
http://msdn.microsoft.com/library/en-us/vclang/html/_core_argument_passing_…
| The compiler generates prolog and epilog code to save and restore
| the ESI, EDI, EBX, and EBP registers, if they are used in the function.
--
d_layer
I was in a strange mood and decided to try to implement something Alex
wanted.
I've done the leg-work on this, but need someone familiar with boot-up
and particularly smp to review this patch. I do not have access to smp,
and do not wish to break it.
This patch implements the /3G switch from within multiboot.S, which is
necessary in order to configure the page tables correctly.
I noticed some code in _main() that was processing a 3G switch on the
command-line, and I can't understand how it could possibly work because
it's not readjusting the page tables, nor does it transition to the
0xC0000000 address space that I can see, so I don't think that code
actually works. If it does, I'm glad to be proved wrong.
The patch I've written makes an assumption that lowmem is available when
application processors execute the code. I can't seem to figure out how
or where the application processor(s) actually get told to start
executing, so I don't know if this assumption is true. However, if it's
not true, if someone could point me to the code that inits the
application processors, I can configure them to pass the needed info via
%ebp or something.
Finally, I haven't actually tried booting this code. I wanted someone to
review it first for obvious blunders, or to tell me, if necessary, that
I've wasted my time ;) If I'm on the right track then, when I'm
feeling motivated enough again, I will actually try booting it.
I built Ros with ACPI=1 but the feature is not working (in real
hardware) as the computer does not go into low power state .
At boot the debug messages displayed are :
DriverBase for acpi.sys : 9ce1300
Advanced Configuration and Power Interface Bus Driver
ACPI: System firmware supports:
+------------------------------------------------------------
| Sx states: +S0 +S1 -S2 -S3 +S4 +S5
+------------------------------------------------------------
What is the status of the ACPI feature ? Is it supported actually ?
Best regards
Gerard