Hash: SHA1

Fred Williams wrote:
> Have you ever actually used a version of Windows?

Windows 1.0 (once), Windows 2/286, Windows 3, 3.1, 3.11, 95, 98, ME,
2000, XP, 2003 and Vista.

> ANY OS that attempts to read in a xGigibyte file into real memory to the
> detriment of the entire system load is not working correctly.  Call it a bug
> or a feature it still sucks.

If the other tasks aren't doing anything then it slows down the reading
task by not using using as much memory as is reasonable.  For example
not using half the RAM for the file caching just in case a background
task may came to life in the future will slow down the file task which
then increases the probability that a background task will be needed.
Getting this stuff right is not easy.  The kernel cannot predict the
future and instead has to use heuristics which involve tradeoffs of
throughput against latency.  There will always be cases where the
heuristics get it wrong, but the goal is to get it right the vast
majority of the time.

Linux has exactly the same issue.  Ultimately a kernel variable named
swappiness is used with a default value, but is administrator adjustable
because even they couldn't work a single correct value for every situation.


Everyone recognises the degenerate cases are bad, but even then it is
questionable.  Do you want the file task to take 1 minute and then have
all your other tasks take 10 seconds to become fully responsive, or do
you want your file task to take 5 minutes while your other tasks are
mostly responsive?

If you have some algorithm, parameters and heuristics that work under
all workloads and configurations then I am sure the operating systems
community would love to hear from you.

Version: GnuPG v1.4.6 (GNU/Linux)

sqlite-users mailing list

Reply via email to