All of lore.kernel.org
 help / color / mirror / Atom feed
From: smoch@web.de (Sören Moch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
Date: Wed, 07 Nov 2012 00:07:01 +0100	[thread overview]
Message-ID: <50999815.4020701@web.de> (raw)
In-Reply-To: <20121106223257.GB30428@lunn.ch>


 >>> For Armada 370/XP we have the same problem that for the commit
 >>> cb01b63, so we applied the same solution: "The default 256 KiB
 >>> coherent pool may be too small for some of the Kirkwood devices, so
 >>> increase it to make sure that devices will be able to allocate their
 >>> buffers with GFP_ATOMIC flag"
 >>
 >> I see a regression from linux-3.5 to linux-3.6 and think there might
 >> be a fundamental problem
 >> with this patch. On my Kirkwood system (guruplug server plus) with
 >> linux-3.6.2 I see following
 >> errors and corresponding malfunction even with further increased
 >> (2M, 4M) pool size:
 >>
 >> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
 >> pool is too small!
 >> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
 >> kernel parameter!
 >>
 >> So I had to downgrade to linux-3.5 which is running without problems.
 >>
 >> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
 >
 > I'm guess its the DVB sticks which are causing the problems. We have a
 > number of kirkwood devices with two SATA devices which had problems
 > until we extended the coherent_pool. The DVB sticks are probably take
 > more coherent RAM. There was also an issue found recently:
 >
 > http://www.spinics.net/lists/arm-kernel/msg203962.html
 >
 > That conversation has gone quiet, but that could be because the
 > participants are at ELCE.
 >
 >          Andrew

OK, I hope this GFP flag correction will help.

Could there be a fragmentation problem in the coherent_pool with the
different drivers running under heavy load?
With a pool size of 1M I see this error after several minutes, with a 4M
pool I see this error after several 10 minutes. Difficult to test, but not
acceptable on a production system.

Soeren

WARNING: multiple messages have this Message-ID (diff)
From: "Sören Moch" <smoch@web.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Lior Amsalem <alior@marvell.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Ian Molton <ian.molton@codethink.co.uk>,
	Jason Cooper <jason@lakedaemon.net>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	m.szyprowski@samsung.com
Subject: Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
Date: Wed, 07 Nov 2012 00:07:01 +0100	[thread overview]
Message-ID: <50999815.4020701@web.de> (raw)
In-Reply-To: <20121106223257.GB30428@lunn.ch>


 >>> For Armada 370/XP we have the same problem that for the commit
 >>> cb01b63, so we applied the same solution: "The default 256 KiB
 >>> coherent pool may be too small for some of the Kirkwood devices, so
 >>> increase it to make sure that devices will be able to allocate their
 >>> buffers with GFP_ATOMIC flag"
 >>
 >> I see a regression from linux-3.5 to linux-3.6 and think there might
 >> be a fundamental problem
 >> with this patch. On my Kirkwood system (guruplug server plus) with
 >> linux-3.6.2 I see following
 >> errors and corresponding malfunction even with further increased
 >> (2M, 4M) pool size:
 >>
 >> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
 >> pool is too small!
 >> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
 >> kernel parameter!
 >>
 >> So I had to downgrade to linux-3.5 which is running without problems.
 >>
 >> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
 >
 > I'm guess its the DVB sticks which are causing the problems. We have a
 > number of kirkwood devices with two SATA devices which had problems
 > until we extended the coherent_pool. The DVB sticks are probably take
 > more coherent RAM. There was also an issue found recently:
 >
 > http://www.spinics.net/lists/arm-kernel/msg203962.html
 >
 > That conversation has gone quiet, but that could be because the
 > participants are at ELCE.
 >
 >          Andrew

OK, I hope this GFP flag correction will help.

Could there be a fragmentation problem in the coherent_pool with the
different drivers running under heavy load?
With a pool size of 1M I see this error after several minutes, with a 4M
pool I see this error after several 10 minutes. Difficult to test, but not
acceptable on a production system.

Soeren

  parent reply	other threads:[~2012-11-06 23:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06 21:28 [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP Sören Moch
2012-11-06 21:28 ` Sören Moch
2012-11-06 22:32 ` Andrew Lunn
2012-11-06 22:32   ` Andrew Lunn
2012-11-06 22:55   ` Sebastian Hesselbarth
2012-11-06 22:55     ` Sebastian Hesselbarth
2012-11-06 23:07   ` Sören Moch [this message]
2012-11-06 23:07     ` Sören Moch
  -- strict thread matches above, loose matches on Subject: below --
2012-10-26 12:30 [PATCH V2 0/4] Adding SATA support for Armada 370/XP Gregory CLEMENT
2012-10-26 12:30 ` [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP Gregory CLEMENT
2012-10-26 12:30   ` Gregory CLEMENT

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50999815.4020701@web.de \
    --to=smoch@web.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.