linux-kernel - Re: [PATCH 0/3] RFC: addition to DMA API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1314904459.1439.24.camel@deneb.redhat.com>
Date:	Thu, 01 Sep 2011 15:14:18 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Will Deacon <will.deacon@....com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Alan Stern <stern@...land.harvard.edu>,
	Ming Lei <ming.lei@...onical.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/3] RFC: addition to DMA API

On Thu, 2011-09-01 at 18:31 +0100, Will Deacon wrote:
> I don't think what we're seeing in this case is caused by mismatched memory
> attributes, especially as passing `nosmp' on the command-line makes the
> performance issue disappear.

I'm coming to think we are dealing with two different problems.

We have the original problem where adding the write buffer flush
to EHCI gives a 4x performance boost to USB. Also adding nosmp to
the cmdline gives pretty much the same boost. This is looking like
something other than just data getting held up in a write buffer.

On the other hand, on a nosmp kernel, I get about 3-4% performance
boost for hdparm -t using the write buffer flush patch vs. without
it.

So, regardless of what turns out to be the actual cause of the 4x
problem, it may still be worthwhile to have the explicit write
buffer sync API if we can't avoid using buffered mappings for DMA.

--Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/