>>>>> "bf" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
bf> sequential access to virtual memory causes reasonably
bf> sequential I/O requests to disk.
no, thrashing is not when memory is accessed randomly instead of
sequentially. It's when the working set of pages is too big to fit in
physical RAM. A program that allocates twice physical RAM size, then
just scans through the entire block over and over, sequentially, will
cause thrashing: the program will run orders of magnitude slower than
it would run if it had enough physical RAM for its working set.
Yes, I am making assumptions:
1. more than one program is running. the other program might just be
xterm, but it's there.
2. programs that allocate memory expect it to be about as fast as
memory usually is.
But, just read the assumptions. They're not really assumptions.
They're just definitions of what is RAM, and what is a time-sharing
system. They're givens.
To benefit, you need your program to loop tens of thousands of times
over one chunk of memory, then stop using that chunk and move on to a
different chunk. This is typical, but it's not sequential. It's
temporal and spatial locality.
A ``well-designed'' or ``second-to-none'' VM subsystem combined with
convenient programs that only use sequentially-accessed chunks of
memory does not avoid thrashing if the working set is larger than
physical RAM.
bf> If using more virtual address space than there is physical
bf> address space always leads to problems, then it would not have
bf> much value.
It's useful when some of the pages are almost never used, like the
part of Mozilla's text segment where the mail reader lives, or large
contiguous chunks of memory that have leaked from buggy C daemons that
kill and restart themselves every hour but leak like upside-down
buckets until then, or the getty processes running on tty's with
nothing connected to them.
It's also useful when you tend to use some pages for a while, then use
other pages. like chew chew chew chew swallow, chew chew chew chew
swallow: maybe this takes two or three times as long to run if the
swallower has to be paged in and out, but at least if you chew for a
few minutes, and if you stop chewing while you swallow like most
people, it won't run 100 times slower. If you make chewing and
swallowing separate threads, then the working set is now the entire
program, it doesn't fit in physical RAM, and the program thrashes and
runs 100 times slower.
sorry for the tangent. I'll shut up now.
pgpB8blizI6Om.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
