On Fri 28-08-15 14:08:10, Navin Parakkal wrote: [...]
Can we do some caching like discussed in this thread ? https://lkml.org/lkml/2015/8/12/964
Some level of caching might be possible, I would have to think about it some more but slab unlike vmalloc is much more volatile so we would end up updating the cached values quite often in the end and that requires the locks. It would be better to collect this information during allocation but that risks affecting hot paths which is not desirable.
That got me thinking that this would atleast alleviate the problem . The proc stuff gets updated only per second or 1/2 a second for example . If you want more detailed and realtime info go to /sys.
Any runtime throttling can be done from the userspace (just do not read the file _that_ often). This is different from what you refer to above because it is glibc which reads /proc/meminfo so an in-kernel throttling is appropriate there. So far I haven't heard _why_ collecting that information during the normal load is useful? What kind of decision you can make based on the numbers? Sure it might be interesting when _debugging_ an unexpected behavior but I wouldn't call that a production run and a sub-optimality is not nice but it is not a killer either.
I don't know how much of this is feasible , but thought would be worth some discussion and learning.
-- Michal Hocko SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org