> We thought about this too, but in some special cases, we do not know the
> correct page size of a memory range. For example when getting a 16M chunk
> from a 16M huge page region which is also aligned to 16M, the first madvise()
> will work fine and the code will assume that the page size is
On Sat, 03 Jul 2010 13:19:07 -0700
Roland Dreier wrote:
> > When registering two memory regions A and B from within
> > the same huge page, we will end up with one node in the tree which covers
> the
> > whole huge page after registering A. When the second MR is registered, a
> node
> > is
> When registering two memory regions A and B from within
> the same huge page, we will end up with one node in the tree which covers the
> whole huge page after registering A. When the second MR is registered, a node
> is created with the MR size rounded to the system page size (as there is n
On Thu, 10 Jun 2010 17:59:28 +0300
Alex Vainman wrote:
> Wrote Roland Dreier:
> > Thanks, nice work. I like this approach. Alex (Vainman) any comments
> > on this?
> >
> > - R.
>
> The solution looks great.
Hi all,
in our further testing, we noticed that there is a substantial problem with
Wrote Roland Dreier:
> Thanks, nice work. I like this approach. Alex (Vainman) any comments
> on this?
>
> - R.
The solution looks great.
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo
Thanks, nice work. I like this approach. Alex (Vainman) any comments
on this?
- R.
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body
On Wed, 02 Jun 2010 14:49:37 -0700
Roland Dreier wrote:
> So if I read this correctly this patch introduces almost a 50% overhead
> in the 1M case... and probably much worse (as a fraction) in say the 64K
> or 4K case. I wonder if that's acceptable?
We don't think this is acceptable, so we like
> without patch:
> 1M memory region120usec
> 16M memory region 1970usec
>
> with patch v2:
> 1M memory region172usec
> 16M memory region 2030usec
So if I read this correctly this patch introduces almost a 50% overhead
in the 1M case... and probably much worse (as a fraction) in
Hi Roland,
we have been working on adressing your review comments and are looking for
feedback regarding v2 now.
Problem description:
When fork support is enabled in libibverbs, madvise() is called for every
memory page that is registered as a memory region. Memory ranges that
are passed to madv
