For reasons which you've described I'm a big fan of removing virtual memory from CPUs altogether. That would speed up things considerably.
On Sun, Dec 8, 2019 at 6:43 PM James K. Lowden <jklow...@schemamania.org> wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
