Regarding remap_pfn_page
Hi, When I mmap pages via remap_pfn_page method would the physical frames assigned the linear address be contiguous? If yes what would happen if I mmap a huge range? Thanks.
On Tue, Jul 19, 2011 at 11:26 PM, mindentropy <mindentropy@gmail.com> wrote:
Hi, When I mmap pages via remap_pfn_page method would the physical frames assigned the linear address be contiguous? If yes what would happen if I mmap a huge range?
Thanks.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
When I mmap pages via remap_pfn_page method would the physical frames assigned the linear address be contiguous?
The place where you typically call remap_pfn_page is mmap handler of your device driver. And you want to assign device memory to user space. Note that the memory (physical pages) might be already allocated and there is no requirement for them to have a kernel linear address assigned to them. For example, on i386, you might allocate pages with from high memory and remap them. These pages may not have kernel linear address. remap_pfn_range is just going to established a secondary virtual address mapping for these pages into the caller process' page tables, irrespective of whether these pages have kernel linear address or not.
If yes what would happen if I mmap a huge range? huge range means you already have huge physical memory to be mapped and user space process has huge virtual memory area to accomodate that. Note that is mapping is specific to one particular process (or threads sharing process address space) so it is fairly possible to establish mmap.
Rajat
When I mmap pages via remap_pfn_page method would the physical frames assigned the linear address be contiguous?
remap_pfn_range is just going to established a secondary virtual address mapping for these pages into the caller process' page tables, irrespective of whether these pages have kernel linear address or not.
Yes I got that. Hopefully the secondary virtual address mapping you are referring to would be the process address space mapping. Just for testing and making it act like I have mmap'd system RAM I have assigned kernel linear addresses to by doing a char *ch = (char *)kmap(pgmem = pfn_to_page(vma->vm_pgoff); setting a value "TEST" and reading it in the userspace process after mmap'ing the physical range. Also I can map different process address space to the same physical page frame right?
If yes what would happen if I mmap a huge range? huge range means you already have huge physical memory to be mapped and user space process has huge virtual memory area to accomodate that. Note that is mapping is specific to one particular process (or threads sharing process address space) so it is fairly possible to establish mmap.
Assuming you have 1 single page size of physical memory. Now when you mmap a huge size would all the different virtual addresses be mapping onto the same physical page frame?
huge range means you already have huge physical memory to be mapped and user space process has huge virtual memory area to accomodate that. Note that is mapping is specific to one particular process (or threads sharing process address space) so it is fairly possible to establish mmap.
Assuming you have 1 single page size of physical memory. Now when you mmap a huge size would all the different virtual addresses be mapping onto the same physical page frame?
Apologize for multiple messages. On my x86_64 machine with 3GB of RAM I cannot mmap a of len=16*1024*1024. So I am assuming it did not find contiguous pages or has run out of contiguous pages(Again assuming that the amount of pages reserved for this is small either the memory hole or the high memory).
On Wed, Jul 20, 2011 at 11:59 PM, mindentropy <mindentropy@gmail.com> wrote:
huge range means you already have huge physical memory to be mapped and user space process has huge virtual memory area to accomodate that. Note that is mapping is specific to one particular process (or threads sharing process address space) so it is fairly possible to establish mmap.
Assuming you have 1 single page size of physical memory. Now when you mmap a huge size would all the different virtual addresses be mapping onto the same physical page frame?
Apologize for multiple messages.
On my x86_64 machine with 3GB of RAM I cannot mmap a of len=16*1024*1024. So I am assuming it did not find contiguous pages or has run out of contiguous pages(Again assuming that the amount of pages reserved for this is small either the memory hole or the high memory).
So your question is rather more confined : Whether you can allocate physically cotigous memory of 16MB, right? Mapping is not an issue here. proper error handling will anyways tell you whether you succeeded or not. I think with kmalloc, you may not get memory larger than 4MB. You can definitely maintain allocation in smaller chunks and maintain a pool on top of them (simple array). with some linear one-to-one scheme between virtual address and your pool, you can assign them to vma. -Rajat
So your question is rather more confined : Whether you can allocate physically cotigous memory of 16MB, right? Mapping is not an issue here. proper error handling will anyways tell you whether you succeeded or not. I think with kmalloc, you may not get memory larger than 4MB.
Yes mapping was never an issue. Contiguous physical frames is an issue. kmalloc limitation is 128KB. __get_page_frames with order higher that 10 would have higher chances of failing. I guess I need to grab as much contiguous memory as possible during boot time. My /proc/buddyinfo on a 512MB RAM machine paints a depressing picture of contiguous chunks.
Hi :) Sorry to kicks in... On Thu, Jul 21, 2011 at 01:29, mindentropy <mindentropy@gmail.com> wrote:
On my x86_64 machine with 3GB of RAM I cannot mmap a of len=16*1024*1024. So I am assuming it did not find contiguous pages or has run out of contiguous pages(Again assuming that the amount of pages reserved for this is small either the memory hole or the high memory).
hm, quite likely you run out of contigous virtual address space that as big as you requested... in above, you requested 16 MiB, right? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Sorry to kicks in... Was wondering where you were :)
hm, quite likely you run out of contigous virtual address space that as big as you requested... in above, you requested 16 MiB, right?
Not virtual address space but physical page frames. Yes I requested 16MB. I want a huge chunk for dma for a high bandwidth pcie(16GB/s!) device . I am thinking in terms of no scatter gather but generally any sane device would have one.
On Thu, Jul 21, 2011 at 11:48 PM, mindentropy <mindentropy@gmail.com> wrote:
Sorry to kicks in... Was wondering where you were :)
hm, quite likely you run out of contigous virtual address space that as big as you requested... in above, you requested 16 MiB, right?
Not virtual address space but physical page frames. Yes I requested 16MB. I want a huge chunk for dma for a high bandwidth pcie(16GB/s!) device . I am thinking in terms of no scatter gather but generally any sane device would have one.
do you see any performance implication of scatter-gather? I think unless you reach limits, performance should not vary much. Just curious to know what sort of device it is targeting 16GB/s?
do you see any performance implication of scatter-gather? Not much. In fact its make life easier. I am worried about dma's not supporting scatter gather and would want to have pretty good performance.
Just curious to know what sort of device it is targeting 16GB/s? Not that it would saturate pcie but would come close. Its a high end framegrabber for scientific purposes.
participants (3)
-
mindentropy -
Mulyadi Santosa -
Rajat Sharma