Feature changed by: Robert Davies (robopensuse) Feature #311177, revision 12 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 #5: Scott Couston (zczc2311) (2011-02-04 00:32:10) (reply to #2) 2011-02-04, 09:32:01 #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) + #6: Robert Davies (robopensuse) (2011-02-04 13:13:21) + I find the explanation of this feature unclear. Scott, are you saying + that you have more Physical RAM than is used by the kernel and + applications, and that you believe that virtual memory is slow? Test + undefinining the swap space, so only 8GB physical memory is available + and see if you find any performance improvement, or low memory + conditions in usage. Considering the installed size of the system, it + is plausible to me, that every demand paged memory page ever read, on + that fat but probably otherwise typical desktop system is indeed + retained in memory. 2.8 GIB is a lot of cached data to have read off + disk (I often install test default desktop into a 10GB system partition + with room to spare). On some distro's like Ubuntu a tmpfs VM filesystem + has been created and populated with most heavily used system libraries + on boot. It would also be simple for end user to configure 2 GB RAM to + be used for /tmp for instance. Personally I suspect that attempts to do + speculative read from disk, will be doomed to the same problems seens + in MS's Vista OS, where excessive disk I/O reduced perceived + performance. Desktop applications similarly suffer from bloat and + poorer performance if they increase memory consumption wastefully, + because of the relatively slow access times of RAM comparted to + instruction cycle time of modern super-scalar multi-GHz CPU. + If a system is over resourced for the work load it is under, + artificially making work will not improve the situation in fact it will + do the opposite. -- openSUSE Feature: https://features.opensuse.org/311177