-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Dec 10, 2016 at 04:54:17AM -0800, Vít Šesták wrote: > Just an idea: Is there a good reason why the he extra RAM assigned to the VM > is calculated by a ratio? Why it is not a constant? > > AFAIU, the reason for the extra RAM is to allow the VM to use the RAM before > qmemman+Xen assign more memory (i.e. to prevent OOM in such case). The memory > management has some latency (AFAIK up to 0.1s of latency is caused by > polling, plus there might be some additional latency) which should be rather > constant. Within this constant time, the processes can allocate at most some > constant amount of memory (because allocating memory requires at least linear > amount of time). This is the reason for constant addition instead of > linearity. Linearity is caused by the need of zeroing the RAM before actually > allocating it.
Linear factor is used as a heuristic - if you have 2 VMs - one using 500MB and another using 2500MB, there is much bigger chance that the later one may request more memory (because you're probably running Firefox/Chrome there ;) ). In some cases it may make sense to split free memory equally, or even not assign at all (keep unallocated). But I think the current default is reasonable. > The issue with fast RAM sounds interesting. In general, having a > faster machine could imply troubles caused by allocating memory too > fast. It would be ideal to have a kernel module or kernel patch that > could handle such situation well (1. pause all processes, 2. notify > dom0, 3. wait for more memory, 4. continue). I know this is > non-trivial – not only for the kernel-mode programming, but also for > lowlevel paradigms required when handling lowmem conditions. Maybe > someone will suggest some alternative to this that would bring most of > its benefits with a fraction of the effort. I would say it is highly non-trivial. Especially the part "pause all processes" (but still be able to communicate with dom0), then "continue" and not introduce any deadlock or other problem. > But maybe all such situations would be handled by swap, which is not > nice, but somehow works. Yes, this is why VMs have swap at all. But it should be last resort so vm.swappiness=0 makes sense. > Some note on the latency: For a given polling the rate (currently AFAIK > 100ms), the polling rate is lower bound for worst-case. When DomUs have a > little extra memory, the worst-case latency could be closer to the lower > bound. > > I am not sure if swap has to be handled as a special case provided > that we have vm.swappiness=0. For vm.swappiness>0, not counting swap > as used memory could be truly disastrous. (When a threshold is reached > and some RAM is subsequently proactively swapped, VM memory > requirements would be lowered, which could trigger proactive swapping > again, until the swap is full.) For vm.swappiness=0, I can see no such > scenario. The VM would start swapping only if the RAM is trully full. (...) AFAIK even if vm.swappiness=0, if something is swapped out, it will not be moved back to RAM unless needed (and then it may force something else to be swapped out). So I think this problem still applies to some degree. > Even if qmemman starts reporting slightly lower memory usage, some > extra memory would be still assigned. (...) > Due to some extra memory, it also would not harm unswapping. When some > more memory is needed, the extra memory is used. Memory-writer then > reports higher memory usage, so more memory is assigned (if allowed > and available). Hmm, this may indeed work. Worth some testing. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYTgcEAAoJENuP0xzK19csXh0H/jOc4ZQiHcQg0yr0Jfcn6grt BfNbcsG5BALVnBu5BH/X4v1qUJA6PkaI6PlxDs34FBf3/5ZThMrcmlxzEMmZkvTg bu6WQwYEfyjGPybeHrpEi7PQ0EgCVQ+2zV1DqfvCVlAdRX4fDpJCD0YEV2MKZ0CW ydqkaxeYLM/FKUwrachT2Ee6JxfBOTpIT4lG4kBualqjKhJ9+aYaz4b4OHmNeIte lR6+FG9UWfWitvL1QNb7UNtKaIR2EV7c584kGoNk4Lmz7qHqtcg2uVcgbWhM0ch3 WXegkBV4yX2NBMIkAZtC/S4QUyfu8+lSmHJCAzKSYCfEcafdOW1VZLhU/8kfYu0= =RgoT -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161212021012.GV16264%40mail-itl. For more options, visit https://groups.google.com/d/optout.
