On 02/14/2016 11:35 AM, arocker@Vex.Net wrote:

...

Data pages, mapped files, are a yes-no-maybe situation. A program might need to read config files at start-up, but those are never read again and never written. Caching them is a waste of time, but how do you tell the cache that?

How hard would it be to invert the significance of the sticky bit? From "keep this around" to "don't bother".

In one sense this happens. The OS knows that the binary/executable files are r/o so their pages are marked as such in the virtual memory again queue. if they age-out they do not get written. IIR the virtual memory system doesn't have a "keep this aground" bit anyway, it just has the ageing queue. If a page gets re-used for any reason its put back to the start of the queue. Hmm. I think there might even be a separate queue for the pages that DO need writing. its more than a decade sing I drilled down on how this works.

Logically, if the file is r-o to the application, it shouldn't update it, so there's no need to keep it in any write cache.

The order is there. The issue is that (a) the application knows this, or rather the application designer knows this and (b) there is currently to mechanism for communicating it from the application to the OS even if (c) the application designer/coder bothered and (d) correctly implemented it. Bt then again, if the file is opened r/o, then I don't think its pages ever go on the write/flush queue. if I have time I'll check, but there are other demands on my time. Anyway, my point is that the OS has smarts and any caching system that tries to bypass theses smarts is Not A Good Thing(tm) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org