I have some memory-checker software. I will put it on my
server if anybody is interested.
I have discovered a VM performance problem that somebody should
look into.
The code:
1/ Allocates PAGE_SIZE buffers (using ordinary malloc()) until
the swap file starts being used (reading /proc --slow).
These buffers are in a linked-list.
2/ Writes all these buffers to a known pattern.
3/ Does lots of XOR operations, etc., on the buffers.
4/ Reads all the buffers to see if any bits are bad.
5/ Reports any bad stuff. If anything is bad, executes
an ioctl() to a dummy driver to get the physical address.
6/ Deallocates all the buffers by running down the linked-list.
7/ Continues <forever> to (1) above.
Here is the performance problem observed. If I ^C out of the program,
killing it outright, with the kernel freeing all the allocated data,
everything is fine. There is little or no swap activity as a result
of this.
If the program deallocates all the buffers, as in (6) above, it will
take even up to 1 whole minute!! At this time, there is an enormous
amount of swap-file activity going on.
Since many programs allocate/deallocate data by setting the break address
via malloc(), this represents a severe performance penalty. Deallocating
pages should not result in any swap-file activity! This activity should
occur only when whatever got swapped out, needs to get swapped back in
and nothing needs to get swapped back in during a deallocation!
Since user's pages are not reordered (or should not be), there should
be no swap activity during page deallocation.
This problem is observed on 2.2.17, 2.4.0-test9, and 2.4.0-test12.
Could a VM guru please comment?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 21:00:22 EST