linux-kernel - RE: [ofa-general] Re: Demand paging for memory regions

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: <Pine.LNX.4.64.0802151044310.12890@schroedinger.engr.sgi.com>
Date:	Fri, 15 Feb 2008 10:45:55 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Caitlin Bestler <Caitlin.Bestler@...erion.com>
cc:	linux-kernel@...r.kernel.org, avi@...ranet.com, linux-mm@...ck.org,
	general@...ts.openfabrics.org, kvm-devel@...ts.sourceforge.net
Subject: RE: [ofa-general] Re: Demand paging for memory regions

On Fri, 15 Feb 2008, Caitlin Bestler wrote:

> > What does it mean that the "application layer has to be determine what
> > pages are registered"? The application does not know which of its
> pages
> > are currently in memory. It can only force these pages to stay in
> > memory if their are mlocked.
> > 
> 
> An application that advertises an RDMA accessible buffer
> to a remote peer *does* have to know that its pages *are*
> currently in memory.

Ok that would mean it needs to inform the VM of that issue by mlocking 
these pages.
 
> But the more fundamental issue is recognizing that applications
> that use direct interfaces need to know that buffers that they
> enable truly have committed resources. They need a way to
> ask for twenty *real* pages, not twenty pages of address
> space. And they need to do it in a way that allows memory
> to be rearranged or even migrated with them to a new host.

mlock will force the pages to stay in memory without requiring the OS to 
keep them where they are.

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