Loading ...
Sorry, an error occurred while loading the content.
 

Info about memory problems on a fatslug

Expand Messages
  • sdm485
    I have been exploring this today and may have gathered some useful information. First, dma_bounce is a feature that is not necessary for the ixp-42x processor
    Message 1 of 1 , Jan 26, 2008
      I have been exploring this today and may have gathered some useful
      information.

      First, dma_bounce is a feature that is not necessary for the ixp-42x
      processor as its' DMA engine can address the entire address space. I
      am testing a 2.6.23.14 kernel with that feature disabled and it is
      working well up to the point that it cannot swap fast enough to handle
      the requests. It very likely causes no problems by leaving it in.

      What appears to be happening is that when an extreme event happens
      like I am running an intensive task that is using 1/2 the memory and
      then launch another one that requests 90% of memory, the usb_storage
      subsystem eventually dies because there are no buffers available for
      the data transfer. I think this is where the problem lies. There is no
      mechanism to block the swap transfers before the usb_storage system dies.

      If I increase the value of /proc/sys/vm/min_free_kbytes from the
      default of 1442 to 2048 on a 128M fatslug, the problem all but
      disappears. I got the problem back by having mtn update the database
      on the slug and then asking for 118M for memtester. At 110M, they both
      happily coexist and I can go from 30M of swap to 145M of swap with no
      problem. Well maybe not happily, mtn slows to a crawl..:)

      But increasing the min_free_kbytes does not actually fix the problem
      but rather puts it out further into the stress limit. The solution is
      to not have a situation where the kernel can not allocate a buffer to
      the device holding the rootfs. It all comes down to a race between the
      kernel asking for a buffer and the usb_storage releasing them. A fast
      USB device probably has fewer problems with this. Otherwise, you must
      guarantee that the usb_storage can handle the data transfers faster
      than the kernel can create them.

      Anyway, the short term solution is to increase the value of
      min_free_kbytes. Doubling is probably good. The default values are
      determined by a bit of a guess anyway. For more info:

      http://people.redhat.com/dduval/kernel/min_free_kbytes.html

      Steve
    Your message has been successfully submitted and would be delivered to recipients shortly.