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: <1429828650.4915.51.camel@kernel.crashing.org>
Date:	Fri, 24 Apr 2015 08:37:30 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jerome Glisse <j.glisse@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	jglisse@...hat.com, mgorman@...e.de, aarcange@...hat.com,
	riel@...hat.com, airlied@...hat.com,
	aneesh.kumar@...ux.vnet.ibm.com,
	Cameron Buschardt <cabuschardt@...dia.com>,
	Mark Hairgrove <mhairgrove@...dia.com>,
	Geoffrey Gerfin <ggerfin@...dia.com>,
	John McKenna <jmckenna@...dia.com>, akpm@...ux-foundation.org
Subject: Re: Interacting with coherent memory on external devices

On Thu, 2015-04-23 at 11:25 -0400, Austin S Hemmelgarn wrote:
> Looking at this whole conversation, all I see is two different views on 
> how to present the asymmetric multiprocessing arrangements that have 
> become commonplace in today's systems to userspace.  Your model favors 
> performance, while CAPI favors simplicity for userspace.

I would say it differently.... when you say "CAPI favors..." it's not CAPI,
it's the usage model we are proposing as an option for CAPI and other
similar technology (there's at least one other I can't quite talk about
yet), but basically anything that has the characteristics defined in
the document Paul posted. CAPI is just one such example.

On another hand, CAPI can also perfectly be used as Christoph describes.

The ability to transparently handle and migrate memory is not exclusive
with the ability for an application to explicitly decide where to allocate
its memory and explicitly move the data around. Both options will be provided.

Before the thread degraded into a debate on usage model, this was an
attempt at discussing the technical details of what would be the best
approach to implement the "transparent" model in Linux. I'd like to go back
to it if possible ...

Cheers,
Ben.


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ