From: Alex Vainman <alexonlists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: alexv-smomgflXvOZWk0Htik3J/w@public.gmane.org,
roland <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alexr-smomgflXvOZWk0Htik3J/w@public.gmane.org
Subject: Re: [PATCH] libibverbs: Add huge page support to ibv_madvise_range()
Date: Thu, 22 Apr 2010 10:35:36 +0300 [thread overview]
Message-ID: <4BCFFC48.4060401@gmail.com> (raw)
In-Reply-To: <ada8wbzi490.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Roland Dreier Wrote:
> > ibv_reg_mr() fails to register a memory region allocated on huge page and not
> > the default page size. This happens because ibv_madvise_range() aligns memory
> > region to the default system page size before calling to madvise() which fails
> > with EINVAL error. madvise() fails because it expects that the start and end
> > pointer of the memory range be huge page aligned.
>
> Seems unfortunate. I wonder if there's a way the kernel madvise could
> help us here?
>
> > +/*
> > + * Get the kernel default huge page size.
> > + */
> > +static int get_huge_page_size()
> > +{
> > + int fd;
> > + char buf[MEMINFO_SIZE];
> > + int mem_file_len;
> > + char *p_hpage_val = NULL;
> > + char *end_pointer = NULL;
> > + char file_name[] = "/proc/meminfo";
> > + const char label[] = "Hugepagesize:";
> > + int ret_val = 0;
> > +
> > + fd = open(file_name, O_RDONLY);
> > + if (fd < 0)
> > + return fd;
> > +
> > + mem_file_len = read(fd, buf, sizeof(buf) - 1);
> > +
> > + close(fd);
> > + if (mem_file_len < 0)
> > + return mem_file_len;
> > +
> > + buf[mem_file_len] = '\0';
> > +
> > + p_hpage_val = strstr(buf, label);
> > + if (!p_hpage_val) {
> > + errno = EINVAL;
> > + return -1;
> > + }
> > + p_hpage_val += strlen(label);
> > +
> > + errno = 0;
> > + ret_val = strtol(p_hpage_val, &end_pointer, 0);
> > +
> > + if (errno != 0)
> > + return -1;
> > +
> > + return ret_val * 1024;
> > +}
>
> This seems to duplicate but only partially a similar function from
> libhugetlbfs. Is there any way we can just use that directly? eg
> libhugetlbfs handles the case where there are multiple huge page sizes
> (and that exists even on mainstream x86 with 2MB and 1GB pages possible
> on the same system).
>
> - R.
> --
> 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
>
Hi Roland,
After the patches, which handle madvise failure, are applied(these pathces were submited under the topic:"libibverbs: Undo changes in memory range tree when madvise() fails"), I would like to renew the discussion about this patch, which actually depends on the above patches, since it may cause madvise failure.
>This seems to duplicate but only partially a similar function from
>libhugetlbfs. Is there any way we can just use that directly? eg
>libhugetlbfs handles the case where there are multiple huge page sizes
>(and that exists even on mainstream x86 with 2MB and 1GB pages possible
>on the same system).
In order to avoid adding additional dependency to libibverbs, maybe we should just to enhance the get_huge_page_size() so it will support multiple huge page sizes?
-Alex
--
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
next prev parent reply other threads:[~2010-04-22 7:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 17:08 [PATCH] libibverbs: Add huge page support to ibv_madvise_range() Alex Vainman
[not found] ` <4B12AA78.7090401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-12-08 14:03 ` Alex Vainman
[not found] ` <4B1E5CA9.3090707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-01-12 9:26 ` Alex Vainman
2010-01-12 14:25 ` Eli Cohen
2010-01-14 15:12 ` Alex Vainman
2010-01-15 18:59 ` Roland Dreier
[not found] ` <ada8wbzi490.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-01-17 9:30 ` Alex Vainman
[not found] ` <4B52D8A8.7060804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-01-17 17:19 ` Roland Dreier
[not found] ` <adak4vghcoo.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-01-18 12:53 ` Alex Vainman
[not found] ` <4B5459E3.2040902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-02-17 14:52 ` Chuck Hartley
2010-04-22 7:35 ` Alex Vainman [this message]
[not found] ` <4BCFFC48.4060401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-05-06 20:51 ` Roland Dreier
[not found] ` <adazl0c92kp.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-13 14:04 ` Alex Vainman
[not found] ` <4BEC06DB.30505-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-05-13 15:50 ` Roland Dreier
[not found] ` <adapr0zsswc.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-14 0:04 ` Pradeep Satyanarayana
[not found] ` <4BEC937F.5000808-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-05-18 5:29 ` Pradeep Satyanarayana
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=4BCFFC48.4060401@gmail.com \
--to=alexonlists-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=alexr-smomgflXvOZWk0Htik3J/w@public.gmane.org \
--cc=alexv-smomgflXvOZWk0Htik3J/w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
--cc=rolandd-FYB4Gu1CFyUAvxtiuMwx3w@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