linux-kernel - Re: Interacting with coherent memory on external devices

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: <1429756456.4915.22.camel@kernel.crashing.org>
Date:	Thu, 23 Apr 2015 12:34:16 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Jerome Glisse <j.glisse@...il.com>, paulmck@...ux.vnet.ibm.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 Wed, 2015-04-22 at 12:14 -0500, Christoph Lameter wrote:
> 
> > Bottom line is we want today anonymous, share or file mapped memory
> > to stay the only kind of memory that exist and we want to choose the
> > backing store of each of those kind for better placement depending
> > on how memory is use (again which can be in the total control of
> > the application). But we do not want to introduce a third kind of
> > disjoint memory to userspace, this is today situation and we want
> > to move forward to tomorrow solution.
> 
> Frankly, I do not see any benefit here, nor a use case and I wonder who
> would adopt this. The future requires higher performance and not more band
> aid.

You may not but we have a large number of customers who do.

In fact I'm quite surprised, what we want to achieve is the most natural
way from an application perspective.

You have something in memory, whether you got it via malloc, mmap'ing a file,
shmem with some other application, ... and you want to work on it with the
co-processor that is residing in your address space. Even better, pass a pointer
to it to some library you don't control which might itself want to use the
coprocessor ....

What you propose can simply not provide that natural usage model with any
efficiency.

It might not be *your* model based on *your* application but that doesn't mean
it's not there, and isn't relevant.

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/