Jump to ID:
QNX Operating System

Project Home

Documents

Discussions

Wiki

Project Info
Forum Topic - OS Benchmarking for 6.4 vs. 6.3.0: (2 Items)
   
 
 
OS Benchmarking for 6.4 vs. 6.3.0  
I've got a customer who's interested in making the switch from 6.3.0 to 6.4 when it's available.  Two very key metrics 
for them are boot time (time to get their application up & running) and memory consumption (they're very close to the 
limit for this product line).  Related to this is the smallest amount of free RAM that the kernel expects before it will
 stop running properly.

They made a similar switch for their 6.2.1B product to 6.3.0.  What they discovered was that in optimizing the 6.3.0 
memory allocator for speed in normal use, the changes negatively impacted total system ram used as well as time required
 to start applications.  The reasoning had to do with default heap blocks and/or some extra work done by the allocator 
during initialization.  Thankfully they were able to substitute the 6.2.1B allocator for the stardard one provided by 6.
3.0 to get their old behavior.  Which ensured that they still met their startup requirements *and* could still fit into 
16MB RAM.

So two questions.
1) Are we going to benchmark things like startup time and overall memory use of 6.4 against 6.3.0?  Clearly we can't do 
it for specific customer applications.  But will we have any idea what we've done and how it impacts various classes of 
user applications?  Like small, big but flat, big but using lots of .so's (like C++)?  Exampnles of things customers 
will need to know would be size of increase or decrease per malloc/per thread/per process.

2) Will we be able to use the old allocator from 6.3.0 or even 6.2.1B if necessary if the 6.4 allocator introduces some 
undesired side-effect?
Re: OS Benchmarking for 6.4 vs. 6.3.0  
For 2), I don't think it's a good idea to work around the OS allocator and provide an own/older one. That as well may 
have undesired side-effects. ;-)

Has the customer tried 6.3.2? AFAIK memory management has been completely rewritten in this kernel version. There also 
was an option to delay memory initialization until first use, if I remember correctly, which should speed up application
 startup time.

With 6.4, I believe the 'big page' support will help your customer. Especially during startup time, memory configuration
 is constantly changing and thus, tons of TLB reloads surely happen. There should be less with 6.4, resulting in better 
speed. 

But all these are just my personal guesses, I'm sure QNX HQ will come up with some solid benchmarks.