Feature changed by: Scott Couston (zczc2311) Feature #311177, revision 8 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 #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 -- openSUSE Feature: https://features.opensuse.org/311177