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: Alexey Korolev <akorolev@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3]HTLB mapping for drivers. Alloc functions & some export symbols(take 2)
Date: Wed, 19 Aug 2009 15:29:27 +1200	[thread overview]
Message-ID: <202cde0e0908182029k73292ee9k6d2782b40beaaa1c@mail.gmail.com> (raw)
In-Reply-To: <20090818082247.GA31469@csn.ul.ie>

Hi,

>>   * Use a helper variable to find the next node and then
>>   * copy it back to hugetlb_next_nid afterwards:
>>   * otherwise there's a window in which a racer might
>
> I haven't read through the whole patchset properly yet, but at this
> point it's looking like you are going to expect drivers to create a file
> and then manually populate the page cache with hugepages they allocate
> directly from here. That would appear to put a large burden of VM
> knowledge upon a device driver author. The patch would also appear to
> expose a lot of hugetlbfs internals.
>
> Have you looked at Eric Munson's patches on the implementation of
> MAP_HUGETLB in the patch set
>
> http://marc.info/?l=linux-mm&m=125025895815115&w=2
>
> ?
Right. Simplicity is very important here and I just haven't find a
good way to make it simpler yet.
Thanks for the link neat approach is a thing I really need now. I've
studied the code and it has quite nice approach which could be
helpful.

>
> In that patchset, it was a very small number of changes required to
> expose a mapping private or shared to userspace.
>
> Would it make more sense to take an approach like that and instead add
> an additional helper within hugetlbfs (instead of the driver) that would
> return a pinned page at a given offset within a hugetlbfs file?
>
I believe it possible to to have a helper. The main problem here is
this: we need to
have a file which provides hugetlb mapping and which is not a part of
Hugetlbfs. So
the file does not have hugetlbfs file operations.It means it is
necessary to call somehow
hugetlb_get_unmapped_area & hugetlbfs_file_mmap for the file on
hugetlbfs associated
with the file related to device.

Probably, if we have non-hugetlbfs file and want to have huge pages
mappings it could make sense to have this approach:

add the following lines to mmap.c/get_unmapped_area function:

         get_area = current->mm->get_unmapped_area;
         if (file && file->f_op && file->f_op->get_unmapped_area)
                get_area = file->f_op->get_unmapped_area;
+       /* Call hugetlb_get_unmapped_area If non hugetlbfs file has
huge page mapping */
+       if (file && mapping_hugetlb(file->f_mapping) &&
!is_file_hugepages(file))
+               get_area = hugetlb_get_unmapped_area;
        addr = get_area(file, addr, len, pgoff, flags);
        if (IS_ERR_VALUE(addr))
                return addr;

add the following lines to mmap.c/mmap_region function:
                }
                vma->vm_file = file;
                get_file(file);
                error = file->f_op->mmap(file, vma);
                if (error)
                        goto unmap_and_free_vma;
+               /*
+                * If non non hugetlbfs file has huge page mapping
mmap must be called twice
+                * first time for proceeding file->fops->mmap second
time we must call hugetlbfs mmap
+               */
+               if (mapping_hugetlb(file->f_mapping) &&
!is_file_hugepages(file))
+                       error =hugetlbfs_file_mmap(file, vma);
+                if (error)
+                        goto unmap_and_free_vma;

                if (vm_flags & VM_EXECUTABLE)

Where mapping_hugetlb is
+static inline int mapping_hugetlb(struct address_space *mapping)
+{
+	if (likely(mapping))
+		return test_bit(AS_HUGETLB, &mapping->flags);
+	return 0;
+}
+
In addition we also need to introduce hugetlbfs_sb_info getting macro
to avoid issues in hugetlb_get_quota/hugetlb_put_quota functions.

In this case a driver just need to announce that file has huge page
mapping (mapping_set_hugetlb(file->f_mapping)), add some pages to page
cache and set-up proper VM flag in flie->f_ops->mmap.

Do you see anything really important being missed in this approach?

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-19  3:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 22:33 Alexey Korolev
2009-08-18  8:22 ` Mel Gorman
2009-08-19  3:29   ` Alexey Korolev [this message]
2009-08-25 11:05     ` 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=202cde0e0908182029k73292ee9k6d2782b40beaaa1c@mail.gmail.com \
    --to=akorolex@gmail.com \
    --cc=akorolev@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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