Mailinglist Archive: opensuse-features (404 mails)

< Previous Next >
[openFATE 311177] RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes
Feature changed by: Scott Couston (zczc2311)
Feature #311177, revision 10
Title: RE-Evaluate the Kernels Cache Buffers and all Associated Caching
Processes

openSUSE.org: Unconfirmed
Priority
Requester: Desirable

Requested by: Scott Couston (zczc2311)
Partner organization: openSUSE.org

Description:
I am going to try to suggest the unthinkable - so please bear with me.
Over a 3 year period I have watched the utilisation of physical RAM on
two X64 PC's. One has 8GIG of RAM the other 4GIG of RAM. I'll just copy
and paste the information to make it easier.
*************************************************
Total memory (RAM): 7.8 GiB Free memory: 4.5 GiB (+ 2.8 GiB Caches)
Free swap: 42.6 GiB
*************************************************
Total memory (RAM): 4.9 GiB Free memory: 1.6 GiB (+ 2.3 GiB Caches)
Free swap: 66.5 GiB
**************************************************
Firstly, I am not going to ever suggest that any change be made to ANY
caching algorithms or other O/S dependency’s, that require the
utilisation of VM. Virtual RAM comes into play with its own costs of
slowing everything down.
The notion of needed more Disk I/O's to stop a hungry application from
issuing an 'Insufficient Memory" warning is out of the question I
believe. Yes the additional Disk I/O's do allow any application to run,
but they are done at the expense of competing with Disk I/O's for file
retrieving and storage of application executables code and in essence
slow everything down! VM is never a desirable situation and competing
for Disk I/O slows everything down - Its not rocket science.
What I do see over time in the 4GIG of Physical RAM is better utilised
in caching algorithms, but none the less leave an enormous pool of
Physical RAM available, even under the highest application load. What I
see over time in the 8GIG of Physical RAM is a huge pool of available
RAM that sits there and never gets utilised.
The 8GIG example may as well only have 4GIG as the presence of a higher
value of Physical RAM go to waste as it is never used. This pool of
available physical RAM is totally wasted, I believe, and offers no
performance enhancing characteristics as the abundant pool remains
untouched by any caching buffers and their dynamic allocation does not
exist.
Rather than reinventing the wheel I have the following suggestion which
may very well kill this request completely or make it far more
difficult to re-invent the wheel. I have had a very long period of
exposure to Netware’s File Servers' dynamic allocation of Physical
RAM and its complexities have been well honed over may years.
If we can just use the dynamic allocation of caching, turbo FAT, and
TTS services we are almost 90% of the way there. I do agree that the
Linux TTS Services are already very strong and possible need no
attention.
The dynamic changes to the utilisation of ALL the Physical RAM on any
Linux O/S Kernel could well do to look at how we dynamically respond
when there is abundant Physical RAM present..
Your comments are very very very most welcome as I am starkly aware
that suggesting this feature is so very very huge and a difficult task
at an Annalists point of view let alone the programmers point of
acceptance for changes in huge amounts of code.
However I am prepared to run it up the flag poll and see who
salutes...:-) Lastly I hope my CR stay fast so as to not ruin the
layout.. .

Business case (Partner benefit):
openSUSE.org: The user benefit is as big as the Linux Kernel itself -
If we can get better use out of the pool of available physical RAM the
better - My current testing over 3 years shows that there is NO
tangible benefit of upwards of 4GIG of RAM!
Without any gain as in above current caching algorithms ( I use this
term "cache", to encompass the Dynamic use of ALL Caching Processes ,
Turbo FAT, TTS, Memory Management and more beneficial use of excess
pool resources etc. etc) fail to be either used to befit the speed of
any PC that has upwards of 4GIG of Physical RAM.
I am sorry I can not express this feature in more simplistic terms - by
its very nature, this feature is very complex!

Discussion:
#1: Scott Couston (zczc2311) (2011-02-03 22:09:32)
Please reject and cancel this Request - Yast will Never Change at a
users Request

#3: Scott Couston (zczc2311) (2011-02-04 00:25:29) (reply to #1)
OOOP! Please Ignore my comment above- I was cutting and pasting into
OTHER feature requests that were no longer valid - Sorry

#2: Scott Couston (zczc2311) (2011-02-04 00:08:31)
QA - Please close/cancel this request on 1 May 2011 if no other action
or no other comments are made other than myself

+ #4: Scott Couston (zczc2311) (2011-02-04 00:31:07)
+ Yes, I am aware that I am dancing with the Devil on this feature
+ request - but as in the above -
+ I am prepared to run it up the flag poll and see who salutes despise
+ the enormity of the feature request...:-)
+ (-Local Expression but I know everyone can understand this)



--
openSUSE Feature:
https://features.opensuse.org/311177

< Previous Next >
This Thread
References