Very Computer

Hello!
The new www server (486, 8MB) with linux 2.0.29 shows this message in the
log files: kernel: Couldn't get a free page.....
I think there should be enough memory overall, because free reports:

             total       used       free     shared    buffers     cached
Mem:          7116       7016        100       4708        124       3056
-/+ buffers:             3836       3280
Swap:        29168       1368      27800

What problems could be caused by this missing of memory?
What can I do to solve this?

Greetings
Marius

--
#############################################################################
#  Marius Heuler   #  LinuX  -  The Choice of the Jilted Generation         #
#     |Rave|       # ------------------------------------------------------ #

# Computer Science #  http://www-info3.informatik.uni-wuerzburg.de/~heuler  #
#   Uni Wuerzburg  #        Don't believe the Hype - Use your Brain!        #
#############################################################################

Quote:>log files: kernel: Couldn't get a free page.....

Basically it means that the kernel couldn't allocate a consequetive chunk
of memory in a time critical section of code (ie, interrupt handler, or NFS
code).  

You can tweak stuff in /proc/sys/vm/freepages, and cause the kernel to more
aggressively page out user pages so the kernel has more free pages (and
therefore, more of a _chance_ to satisfy the request).  However, that
doesn't solve the problem, merely delay's when you'll see the symptom.

mrc

        another dimension with:
 >Hello!
 >The new www server (486, 8MB) with linux 2.0.29 shows this message in the
 >log files: kernel: Couldn't get a free page.....
 >I think there should be enough memory overall, because free reports:
 >
 >             total       used       free     shared    buffers     cached
 >Mem:          7116       7016        100       4708        124       3056
 >-/+ buffers:             3836       3280
 >Swap:        29168       1368      27800

        Why linux doesn't handle the request, I don't know, but more
        (real) memory will fix the problem. This never has occurred
        on my personal machine (40 MB now, but run w/ as little as
        16 using X) and only happens on a news server that I work on
        when innd has become about as large as the physical memory,
        (once a week, maybe) in which case, restarting innd fixes
        it.

--
Spend a day with NT and
Learn to appreciate VMS
and the raw power of DCL

I don't have the time to see what is going on there, but a system crash
like that should not happen.

Quote:> therefore, more of a _chance_ to satisfy the request).  However, that
> doesn't solve the problem, merely delay's when you'll see the symptom.

Jost

I don't have the time to see what is going on there, but a system crash
like that should not happen.

Quote:> therefore, more of a _chance_ to satisfy the request).  However, that
> doesn't solve the problem, merely delay's when you'll see the symptom.

Jost

If you switch to a console (w/o X) and press shift-ScrLock, you'll get
a dump with the following info in it

Mem-info:
Free pages:        1032kB
 ( 124*4kB 3*8kB 4*16kB 2*32kB 2*64kB 2*128kB = 1032kB)

Linux keeps a list of free pages grouped according to the maximum
contiguous size. I.e. if there is 2 8kB regions that can be fused end
to end to form a 16kB region, Linux will do so.)

When a "Couldn't get a free page..." incident happens, all blocks of
(say) 8kB or more have been used, whereas many smaller blocks are
still around. Fragmentation. Since there's plenty of free pages *in
total* Linux sees no reason to swap things out in order to get more
memory, but the net-driver or whatever sits in a loop waiting for a
large enough block to appear. Deadlock. (And maybe half an hour later,
by some random event, an 8k block appears and everything continues as
if nothing ever happened.)

As you might have noticed, my numbers are probably bigger than yours.
That's because I do an

echo '128 192 256' > /proc/sys/vm/freepages

in my startup files. (Default is '40 60 80'). This tells Linux to
start swapping if there's less than 1024K (256 * 4K) memory left, and
do it increasingly aggressively as the free amount drops below 768K
and 512K watermarks. More free memory is likely to be more difficult
to get completely fragmented, but it *can* still happen. That's what
Mike meant with "delays the symptom".

--
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N  
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918

Quote:> Mem-info:
> Free pages:        1032kB
>  ( 124*4kB 3*8kB 4*16kB 2*32kB 2*64kB 2*128kB = 1032kB)

> Linux keeps a list of free pages grouped according to the maximum
> contiguous size. I.e. if there is 2 8kB regions that can be fused end
> to end to form a 16kB region, Linux will do so.)

Quote:> When a "Couldn't get a free page..." incident happens, all blocks of
> (say) 8kB or more have been used, whereas many smaller blocks are
> still around. Fragmentation. Since there's plenty of free pages *in
> total* Linux sees no reason to swap things out in order to get more
> memory, but the net-driver or whatever sits in a loop waiting for a
> large enough block to appear. Deadlock.

Regards,
Wolfram.

--
________________________________________________________________________
T    i    m    o    t    h    y              W    a    t    s    o    n

  __/| Something there is that doesn't love a wall, that wants it down

i got this problem, when i tried to format a large partition (3 GB),
but i have networking running. I have tried it serveral times
with a kernel 2.0.30 without success, then using 2.0.27 it worked,
and on an other test with 2.0.30 it worked also (all tests are running
on the same machine P166, adaptec 2940, 32 MB ram).

I have testet it also with a running X, which causes a complete hang
of the machine.

Uli
--

http://people.frankfurt.netsurf.de/uli
Truly great madness can not be achieved without significant
intelligence. (Henrik Tikkanen)

 ftp://ftp.kernel.org/pub/linux/kernel/davem/pre-patch-2.0.31-2.gz

(don't be intimidated by the size of that patch, the changes to the
buffering code are very minor).

Regards,
Wolfram.