Messages in this thread | | | Date | Wed, 19 Aug 2009 21:01:17 +1200 | Subject | Re: HTLB mapping for drivers. Driver example | From | Alexey Korolev <> |
| |
Mel,
> > This seems a lot of burden to put on a device driver, particularly with > respect to the reservations.
Thanks a lot for review you did. That is right. I don't like this burden as well. > >> File operations of /dev/hpage_map do the following: >> >> In file open we associate mappings of /dev/xxx with the file on hugetlbfs (like it is done in ipc/shm.c) >> file->f_mapping = h_file->f_mapping; >> >> In get_unmapped_area we should tell about addressing constraints in case of huge pages by calling hugetlbfs procedures. (as in ipc/shm.c) >> return get_unmapped_area(h_file, addr, len, pgoff, flags); >> >> We need to let hugetlbfs do architecture specific operations with mapping in mmap call. This driver does not reserve any memory for private mappings >> so driver requests reservation from hugetlbfs. (Actually driver can do this as well but it will make it more complex) >> >> The exit procedure: >> * removes memory from page cache >> * deletes file on hugetlbfs vfs mount >> * free pages >> >> Application example is not shown here but it is very simple. It does the following: open file /dev/hpage_map, mmap a region, read/write memory, unmap file, close file. >> > > For the use-model you have in mind, could you look at Eric Munson's patches > and determine if the target application would have been happy to call the > following please? > > mmap(0, len, prot, MAP_ANONYMOUS|MAP_HUGETLB, 0, 0) > Hmm. But how can I at least identify which driver this call is addressed to?
Thanks, Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |