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.0802141836070.4898@schroedinger.engr.sgi.com>
Date:	Thu, 14 Feb 2008 18:37: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 Thu, 14 Feb 2008, Caitlin Bestler wrote:

> So any solution that requires the upper layers to suspend operations
> for a brief bit will require explicit interaction with those layers.
> No RDMA layer can perform the sleight of hand tricks that you seem
> to want it to perform.

Looks like it has to be up there right.
 
> AT the RDMA layer the best you could get is very brief suspensions for 
> the purpose of *re-arranging* memory, not of reducing the amount of 
> registered memory. If you need to reduce the amount of registered memory 
> then you have to talk to the application. Discussions on making it 
> easier for the application to trim a memory region dynamically might be 
> in order, but you will not work around the fact that the application 
> layer needs to determine what pages are registered. And they would 
> really prefer just to be told how much memory they can have up front, 
> they can figure out how to deal with that amount of memory on their own.

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