Ring buffers in userland

Internal structure and you change requests/suggestions
  • Hi hidnplayr,
    hidnplayr wrote:Does anyone know
    Not me :D

    I'm not sure I understood your question. Do you want something like io_uring?
  • https://en.wikipedia.org/wiki/Circular_ ... timization

    Analog to create_ring_buffer in kernel, but accessible from application/libraries.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • After reading this post I managed to get two adjacent virtual pages mapped to the same physical page, RW accessible from the application:

    Code: Select all

    stdcall user_alloc, 0x2000
    <-lin
    
    call alloc_page
    <-phys
    
    stdcall map_page, lin, phys, PG_UWR
    stdcall map_page, lin+0x1000, phys, PG_UWR
    
    May be it makes sense to create create_ring_buffer_user and create_ring_buffer_common and move most part of create_ring_buffer to the latter one.
  • dunkaist wrote:After reading this post I managed to get two adjacent virtual pages mapped to the same physical page, RW accessible from the application:

    Code: Select all

    stdcall user_alloc, 0x2000
    <-lin
    
    call alloc_page
    <-phys
    
    stdcall map_page, lin, phys, PG_UWR
    stdcall map_page, lin+0x1000, phys, PG_UWR
    
    May be it makes sense to create create_ring_buffer_user and create_ring_buffer_common and move most part of create_ring_buffer to the latter one.
    Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.
    (And didn't find yet how/where it is mapped.)

    Also, how to undo everything when we're done?
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • hidnplayr wrote:Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.
    (And didn't find yet how/where it is mapped.)
    Doesn't user_alloc allocates memory lazily, i.e. only virtual pages immediately, physical pages in PF handler?
    If this is the case, then it is clear why you didn't find where user_alloc works with physical pages.
    hidnplayr wrote:Also, how to undo everything when we're done?
    Again, I'm just interpreting this post.
    I see that user_free calls free_page too. Isn't it enough?
  • dunkaist wrote:
    hidnplayr wrote:Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.
    (And didn't find yet how/where it is mapped.)
    Doesn't user_alloc allocates memory lazily, i.e. only virtual pages immediately, physical pages in PF handler?
    If this is the case, then it is clear why you didn't find where user_alloc works with physical pages.
    It seems you are right. Allocation is done in "page_fault_handler" in memory.inc
    It explains the magic bit flag '2' sometimes referred to in the code as 'reserved'.

    Thanks!
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 3 guests