[Lse-tech] DBT2 workload improvement with 2.5.68mjb2 and CONFIG_05GB=y

[Mary E. M. <mar...@os...>]

Martin,

I finally had a chance to try your 2.5.68mjb2 kernel with the
CONFIG_05GB=y configuration setting.  

I ran the DBT2 non-cached case with the database cached size
(data_cache) set to the highest possible on previous 2.5 kernels-
(340,000 8k "pages" for SAP-DB) limited by logical address space. 

With CONFIG_05GB=y I was able to raise the database data_cache size
setting from 340,000 to 400,000.

Reran and got nearly an 8% improvement surely due to grabbing more
memory that I could not do before.  Swapping remains zero. 
                                
Test machine is 8way x-370 Pentium III (Cascades) 700MHz with 4GB
memory. Here are the figures with a set of runs from 2.5.67mjb2 for
comparison ( for the metric NOTPM, bigger is better):


Kernel:        2.5.67 mjb2     2.5.68mj2     2.5.68mj2
Config:        CONFIG_1GB=y    CONFIG_05GB=y CONFIG_05GB=y
DATA_CACHE     340000          340000        400000
DBT2 workload  non-cached      non-cached    non-cached
average NOTPM  1656.3          1665.3        1794.6
stdev          6.0             2.5           4.5
% Improvement  base            0.54          8.35
% Improvement  n/a             base          7.76

(If the above gets jumbled, that's a 7.76% improvement larger versus
smaller memory setting for 2.5.68mjb2.)

It appears that for SAP-DB we are in fact using more physical memory
with this logical address enlargement.  If I understand  "Active"  from
/proc/meminfo (see below) made after the db warm-up period, the
difference in the two 2.5.68mjb2 runs roughly equals the increase in
data_cache I made.  I can also see the address ranges assigned
increased accordingly in the database startup messages.  (BTW didn't
have to hardcode TASK_UNMAPPED_BASE as your patch gave me E0000000/16
for my 4GB set up).  

Still looks like I have more free memory (LowFree and HighFree).  Why is
there so much free memory remaining?  Is the kernel needing that
little?  I'd like to grab more if I can.

It seems like this could be a win for customers using databases/apps
thatshare memory this way, assuming one could determine much memory is
safe to grab. 

Regards,
-- 
Mary Edie Meredith <mar...@os...>
Open Source Development Lab

***********************
meminfo after warmup:

Run with 400,000 data cache (first run after reboot)

MemTotal:      3885416 kB
MemFree:        397348 kB
Buffers:         20048 kB
Cached:          80456 kB
SwapCached:          0 kB
Active:        3380088 kB<--------
Inactive:        71360 kB
HighTotal:     3538904 kB
HighFree:       102720 kB
LowTotal:       346512 kB
LowFree:        294628 kB
SwapTotal:     4194272 kB
SwapFree:      4194272 kB
Dirty:             340 kB
Writeback:           0 kB
Mapped:        3362968 kB
Slab:            15796 kB
Committed_AS:  3697380 kB
PageTables:       4492 kB
VmallocTotal:   114680 kB
VmallocUsed:      2144 kB
VmallocChunk:   112536 kB


As opposed to the run with
the 340,000 data-cache setting
(first run after reboot)

MemTotal:      3885416 kB
MemFree:        898780 kB
Buffers:         17692 kB
Cached:          74380 kB
SwapCached:          0 kB
Active:        2879048 kB <------
Inactive:        72072 kB
HighTotal:     3538904 kB
HighFree:       600704 kB
LowTotal:       346512 kB
LowFree:        298076 kB
SwapTotal:     4194272 kB
SwapFree:      4194272 kB
Dirty:             316 kB
Writeback:           0 kB
Mapped:        2870208 kB
Slab:            15324 kB
Committed_AS:  3193152 kB
PageTables:       3916 kB
VmallocTotal:   114680 kB
VmallocUsed:      2144 kB
VmallocChunk:   112536 kB