From: Shachar Raindel <raindel@mellanox.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Yishai Hadas <yishaih@mellanox.com>,
"dledford@redhat.com" <dledford@redhat.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Or Gerlitz <ogerlitz@mellanox.com>, Tal Alon <talal@mellanox.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [RFC contig pages support 1/2] IB: Supports contiguous memory operations
Date: Sun, 13 Dec 2015 12:48:05 +0000 [thread overview]
Message-ID: <AM4PR05MB14603FC8169D50AD2A8F5AA3DCEC0@AM4PR05MB1460.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20151209183940.GA4522@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Wednesday, December 09, 2015 8:40 PM
>
> On Wed, Dec 09, 2015 at 10:00:02AM +0000, Shachar Raindel wrote:
> > As far as gain is concerned, we are seeing gains in two cases here:
> > 1. If the system has lots of non-fragmented, free memory, you can
> create large contig blocks that are above the CPU huge page size.
> > 2. If the system memory is very fragmented, you cannot allocate huge
> pages. However, an API that allows you to create small (i.e. 64KB,
> 128KB, etc.) contig blocks reduces the load on the HW page tables and
> caches.
>
> None of that is a uniqueue requirement for the mlx4 devices. Again,
> please work with the memory management folks to address your
> requirements in a generic way!
I completely agree, and this RFC was sent in order to start discussion
on this subject.
Dear MM people, can you please advise on the subject?
Multiple HW vendors, from different fields, ranging between embedded SoC
devices (TI) and HPC (Mellanox) are looking for a solution to allocate
blocks of contiguous memory to user space applications, without using huge
pages.
What should be the API to expose such feature?
Should we create a virtual FS that allows the user to create "files"
representing memory allocations, and define the contiguous level we
attempt to allocate using folders (similar to hugetlbfs)?
Should we patch hugetlbfs to allow allocation of contiguous memory chunks,
without creating larger memory mapping in the CPU page tables?
Should we create a special "allocator" virtual device, that will hand out
memory in contiguous chunks via a call to mmap with an FD connected to the
device?
Thanks,
--Shachar
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-12-13 12:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1449587707-24214-1-git-send-email-yishaih@mellanox.com>
[not found] ` <1449587707-24214-2-git-send-email-yishaih@mellanox.com>
2015-12-08 15:18 ` Christoph Hellwig
2015-12-08 17:15 ` Jason Gunthorpe
2015-12-09 10:00 ` Shachar Raindel
2015-12-09 17:48 ` Jason Gunthorpe
2015-12-09 18:39 ` Christoph Hellwig
2015-12-13 12:48 ` Shachar Raindel [this message]
2015-12-22 14:59 ` Vlastimil Babka
2015-12-23 16:30 ` Shachar Raindel
2016-01-04 14:43 ` Vlastimil Babka
2016-01-04 14:44 ` Vlastimil Babka
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=AM4PR05MB14603FC8169D50AD2A8F5AA3DCEC0@AM4PR05MB1460.eurprd05.prod.outlook.com \
--to=raindel@mellanox.com \
--cc=dledford@redhat.com \
--cc=hch@infradead.org \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=talal@mellanox.com \
--cc=yishaih@mellanox.com \
/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