Re: Some VM timings and Linux

Gerard Roudier (
Thu, 20 Mar 1997 23:04:51 +0000 (GMT)

On Sun, 16 Mar 1997, Andrew P. Mullhaupt wrote:

> Dear Linux-Kernelers.
> Here is a performance observation that I would like to understand in
> terms of what Linux is doing.
> I have two programs, 'double' and 'double2'. They both basically do the
> same thing, which is that both
> double foo goo
> and
> double2 foo goo
> will achieve the same result as
> cat foo foo > goo
> The first version (double) maps the file foo, creates, sizes and maps
> the file goo, and then calls memcpy() to fill in the first half of goo.
> It then calls msync() with MS_ASYNC | MS_INVALIDATE on the first half of
> goo to tell the kernel it doesn't need those pages any more. Then it
> calls memcpy() again to fill in the second half of goo.
> The second (and possibly best version for Unix) maps the file
> foo, opens goo, and then does two calls to write() to fill in goo. This
> is probably better than the first version since you only need address
> space for one copy of the file, instead of two or more.
> In this example, both Linux and Solaris have enough memory to accomodate
> _both_ the file foo and goo at the same time. foo was 8.7 MBytes and goo
> was therefore 17.4 Mbytes. Since the P200MMX machine has 32 MBytes SDRAM
> and 17MBytes disk cache, there should be no real problem here. The
> ultrasparc has 380MBytes of memory, but, as you will see from the
> timings, this is probably not relevant beyond the fact that it has
> enough memory.

What a nice test to make the page cache eat the whole available memory.
If, at this moment, the kernel need memory at GFP_ATOMIC priority, it
may be infortunate.

For example, if the buffer cache (fs/buffer.c) decides to get memory
for buffer headers (it uses GFP_ATOMIC priority), it will be
unfortunate. Because the involved loop only only test "unused_list" which
is not immediately filled on io completion, that can take a while ...
The simple patch I sent some days ago should make a difference, in my
opinion ...
In fact, this example is my explanation of the problem you observed.
The buffer cache probably will try to get more buffers headers since
lots of buffers headers are used for syncing pages and IOs are at this
moment probably not yet completed.