On 8/23/21 11:29 AM, David Hildenbrand wrote: > On 23.08.21 11:23, Peter Maydell wrote: >> On Mon, 23 Aug 2021 at 09:40, David Hildenbrand <da...@redhat.com> wrote: >>> Not opposed to printing the size, although I doubt that it will really >>> stop similar questions/problems getting raised. >> >> The case that triggered this was somebody thinking >> -m took a byte count, so very likely that an error message >> saying "you tried to allocate 38TB" would have made their >> mistake clear in a way that just "allocation failed" did not. >> It also means that if a future user asks us for help then >> we can look at the error message and immediately tell them >> the problem, rather than going "hmm, what are all the possible >> ways that allocation might have failed" and going off down >> rabbitholes like VM overcommit settings... > > We've had similar issues recently where Linux memory overcommit handling > rejected the allocation -- and the user was well aware about the actual > size. You won't be able to catch such reports, because people don't > understand how Linux memory overcommit handling works or was configured. > > "I have 3 GiB of free memory, why can't I create a 3 GiB VM". "I have 3 > GiB of RAM, why can't I create a 3 GiB VM even if it won't make use of > all 3 GiB of memory". > > Thus my comment, it will only stop very basic usage issues. And I agree > that looking at the error *might* help. It didn't help for the cases I > just described, because we need much more system information to make a > guess what the user error actually is.
Is it possible to get the maximal overcommitable amount on Linux?
