Mailinglist Archive: opensuse-features (409 mails)

< Previous Next >
[New: openFATE 311177] RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes
Feature added by: Scott Couston (zczc2311)

Feature #311177, revision 1
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.. .

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

< Previous Next >
List Navigation
This Thread
Follow Ups
References