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.
Date: Mon, 18 Dec 2000 13:54:56 -0500 (EST)
From: "Richard B. Johnson" <[email protected]>
6/ Deallocates all the buffers by running down the linked-list.
...
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.
How exactly are these buffers allocated/deallocated? Are you
absolutely certain that the deallocation process does not make loads
from or stores into the buffers as a free(3) implementation would?
That would cause the pages to be sucked back from swap space.
Later,
David S. Miller
[email protected]
On Mon, 18 Dec 2000, David S. Miller wrote:
> Date: Mon, 18 Dec 2000 13:54:56 -0500 (EST)
> From: "Richard B. Johnson" <[email protected]>
>
> 6/ Deallocates all the buffers by running down the linked-list.
>
> ...
>
> 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.
>
> How exactly are these buffers allocated/deallocated? Are you
> absolutely certain that the deallocation process does not make loads
> from or stores into the buffers as a free(3) implementation would?
>
> That would cause the pages to be sucked back from swap space.
>
Well I just use free(), nothing more, nothing special, just like
a typical data-base program. Free should just set a new break
address after the reclaimed data falls below some watermarks it
has established. Both malloc() and free(), use already allocated
data-space for their work-space (last time I looked at library code).
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.
Date: Mon, 18 Dec 2000 14:09:00 -0500 (EST)
From: "Richard B. Johnson" <[email protected]>
Well I just use free(), nothing more, nothing special, just like a
typical data-base program. Free should just set a new break
address after the reclaimed data falls below some watermarks it has
established. Both malloc() and free(), use already allocated
data-space for their work-space (last time I looked at library
code).
malloc and free maintain their free buffers pools using linked lists,
thus a free() does two stores to the (2 * sizeof(void *)) bytes before
or after that buffer. Thus the swapping.
Use mmap()/munmap() directly and manage things totally yourself to get
rid of this.
Later,
David S. Miller
[email protected]