Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
>>>> Hi,
>>>> doesn't this patch [1] have some relevance for us as well? As we use
>>>> xnarch_remap_io_page_range also for non-IO memory, I'm hesitating to
>>>> suggest that we apply this unconditionally at xnarch level. Ideas welcome.
>>> Yes, I think it makes a lot of sense on powerpc at least, since doing so 
>>> will
>>> set the PAGE_GUARDED bit as well, and we obviously want to avoid any
>>> out-of-order access of I/O memory.
>>> (I don't see the reason to force the VM_RESERVED and VM_IO on the vma 
>>> though,
>>> since remap_pfn_range will do it anyway.)
>> No, I was talking about cases where we may pass kmalloc'ed memory to
>> xnarch_remap_io_page_range. In that case, caching and out-of-order
>> access may be desired for performance reasons.
> xnarch_remap_io_page_range is intended for I/O memory only, some assumptions 
> are
> made on this. rtdm_mmap_buffer() should be fixed; it would be much better to
> define another internal interface at xnarch level to specifically perform
> kmalloc mapping.

Yeah, probably. But I think the issue is not just limited to RTDM. The
xnheap can be kmalloc-hosted as well.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to