linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Korolev <akorolex@gmail.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Eric Munson <linux-mm@mgebm.net>,
	Alexey Korolev <akorolev@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3]HTLB mapping for drivers (take 2)
Date: Fri, 28 Aug 2009 00:02:05 +1200	[thread overview]
Message-ID: <202cde0e0908270502p3ea403ddr516945084372ffc4@mail.gmail.com> (raw)
In-Reply-To: <20090825105341.GB21335@csn.ul.ie>

>
>> If reservation only, then it is necessary to keep a gfp_mask for a
>> file somewhere. Would it be Ok to keep a gfp_mask for a file in
>> file->private_data?
>>
>
> I'm not seeing where this gfp mask is coming out of if you don't have zone
> limitations. GFP masks don't help you get contiguity beyond the hugepage
> boundary.
Contiguity is different. It is not related to GFP mask.
Requirement to have large contigous buffer is dictated by h/w. Since
this is very specific case it will need very specific solution. So if
providing this, affects on usability of kernel interfaces it's better
to left interfaces good.
But large DMA buffers with large amount of sg regions is more common.
DMA engine often requires 32 address space. Plus memory must be non
movable.
That raises another question: would it be correct assumiing that
setting sysctl hugepages_treat_as_movable won't make huge pages
movable?
>
> If you did need the GFP mask, you could store it in hugetlbfs_inode_info
> as you'd expect all users of that inode to have the same GFP
> requirements, right?
Correct. The same GFP per inode is quite enough.
So that way works. I made a bit raw implementation, more testing and
tuning and I'll send out another version.

Thanks,
Alexey

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

  reply	other threads:[~2009-08-27 12:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 22:24 Alexey Korolev
2009-08-18 10:29 ` Eric Munson
2009-08-19  5:48   ` Alexey Korolev
2009-08-19 10:05     ` Mel Gorman
2009-08-19 10:35       ` Eric B Munson
2009-08-20  7:03       ` Alexey Korolev
2009-08-25 10:47         ` Mel Gorman
2009-08-25 11:00           ` Benjamin Herrenschmidt
2009-08-25 11:10             ` Mel Gorman
2009-08-26  9:58               ` Benjamin Herrenschmidt
2009-08-26 10:05                 ` Mel Gorman
2009-08-24  6:14       ` Alexey Korolev
2009-08-25 10:53         ` Mel Gorman
2009-08-27 12:02           ` Alexey Korolev [this message]
2009-08-27 12:50             ` Mel Gorman

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=202cde0e0908270502p3ea403ddr516945084372ffc4@mail.gmail.com \
    --to=akorolex@gmail.com \
    --cc=akorolev@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mm@mgebm.net \
    --cc=mel@csn.ul.ie \
    /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