Regarding remap_pfn_page

Regarding remap_pfn_page

[mindentropy]

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.

Regarding remap_pfn_page

[Rajat Sharma]

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

Regarding remap_pfn_page

[mindentropy]

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

Regarding remap_pfn_page

[mindentropy]

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

Regarding remap_pfn_page

[mindentropy]

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

Regarding remap_pfn_page

[Rajat Sharma]

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

Regarding remap_pfn_page

[mindentropy]

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

Regarding remap_pfn_page

[Mulyadi Santosa]

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

Regarding remap_pfn_page

[mindentropy]

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

Regarding remap_pfn_page

[Rajat Sharma]

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?

Regarding remap_pfn_page

[mindentropy]

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