public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Wright <tim.wright-c+vHNXOUHMmEK/hMebVsMw@public.gmane.org>
To: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Naïve question wrt ibv_reg_mr(), pinned pages and Linux VM
Date: Fri, 12 Mar 2010 21:36:48 -0500	[thread overview]
Message-ID: <C7C03A40.9C2%tim.wright@rnanetworks.com> (raw)

Hello everybody,
I have a question regarding behavior of the memory pinning using
ibv_reg_mr() on RHEL/Centos 5.3/OFED-1.4.1. This may be more a Linux
feature/issue, and I apologize if that is the case. Here is the scenario

1. An application runs which allocates a significant fraction of the system
memory as RDMA buffers (e.g. 3GB of ram on a 4GB system). These are setup
using ibv_reg_mr(). It is clear that the pages are pinned from the kernel
perspective. With just this program running, the resident set size of the
program approaches the allocation size.
2. If other memory-intensive processes are now started, the resident set
size of the RDMA-using program shrinks dramatically.
3. Even if the other memory-intensive programs are stopped, and the
RDMA-using program is forced to read its memory, the resident set never
grows to a ³reasonable² size again.

My potentially foolish assumptions are/were that:
i) Since the memory is pinned anyway, it would be locked into the process
address space, and
ii) even if that were not the case, that the process would be able to regain
a large RSS when any competing processes stopped.

For ii), it almost seems that the VM doesn¹t realize that the pages it would
be grabbing back are already resident and therefore won¹t actually take any
more memory.

Clearly, I can use mlock() to avoid the issue, but I was wondering if I have
missed something obvious here. Any clues/brickbats gratefully received!

Regards,

Tim Wright

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2010-03-13  2:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-13  2:36 Tim Wright [this message]
     [not found] ` <C7C03A40.9C2%tim.wright-c+vHNXOUHMmEK/hMebVsMw@public.gmane.org>
2010-03-14 10:22   ` Naïve question wrt ibv_reg_mr(), pinned pages and Linux VM Eli Cohen
     [not found]     ` <20100314102239.GA23358-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
2010-03-14 19:56       ` Tim Wright
     [not found]     ` <C7C25E98.10DB%tim.wright@rnanetworks.com>
     [not found]       ` <C7C25E98.10DB%tim.wright-c+vHNXOUHMmEK/hMebVsMw@public.gmane.org>
2010-03-15  7:52         ` Eli Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C7C03A40.9C2%tim.wright@rnanetworks.com \
    --to=tim.wright-c+vhnxouhmmek/hmebvsmw@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox