On Sat, 7 Dec 2019 05:23:15 +0000 Simon Slavin <slav...@bigfraud.org> wrote:
> (Your operating system is allowed to do this. Checking how much > memory is available for every malloc takes too much time.) Not really. Consider that many (all?) operating systems before Linux that supported dynamic memory returned an error if the requested amount couldn't be supplied. Some of those machines had 0.00001% of the processing capacity, and yet managed to answer the question reasonably quickly. The origin of oversubscribed memory rather has its origins in the changed ratio of the speed of RAM to the speed of I/O, and the price of RAM. As RAM prices dropped, our machines got more RAM and the bigger applications that RAM supported. As memory got faster, relatively, the disk (ipso facto) has gotten slower. Virtual memory -- the hallmark of the the VAX, 4 decades ago -- has become infeasibly slow both because the disk is relatively slower than it was, and because more is being demanded of it to support today's big-memory applications. Swapping in Firefox, at 1 GB of memory, who knows why, is a much bigger deal than Eight Megabytes and Constantly Swapping. If too much paging makes the machine too slow (however measured) one solution is less paging. One administrative lever is to constrain how much paging is possible by limiting the paging resource: swap space. However, limiting swap space may leave the machine underutilized, because many applications allocate memory they never use. Rather than prefer applications that use resources rationally or administer machines to prevent thrashing, the best-effort, least-effort answer was lazy allocation, and its infamous gap-toothed cousin, the OOM. Nothing technical mandates oversubscribed memory. The problem, as ever, is not with the stars, but with ourselves. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
