3 ms·

Wouldn't using those tricks cause significant performance loss due to kernel syscall and page table updates needed for each virtual_alloc call?

by magnat 9y ago

ZeppelinPL 9y ago
Yeah, using syscall to get uniqueId is kind of controversial...
- deleted 9y ago
  [deleted]
- gizmo 9y ago
  You don't do a syscall for _every_ uniqueId, only once every PAGE_SIZE. It's not that expensive. Not every object needs a unique identifier. Objects that need them tend to be larger and have indeterminate lifecycles. Otherwise the overhead of storing a unique id would by itself be egregious, regardless of the process of generating the id. If you can afford to store the id then you can afford the overhead of an occasional syscall.
  - amscanne 9y ago
    There are secondary effects that also make this not a great idea. You may wind up slowing leaking vmas (the kernel needs to track what’s been mapped, even if it doesn’t allocate physical pages). This makes future mmap calls and page faults slower. Generating a uniqueID is trivial and super fast (one atomic operation). What’s the benefit here?
jcbeard 9y ago
yes...yes they would.
DSMan195276 9y ago
I don't know for sure for Windows, but for Linux for most of these the answer is no. Until the physical memory is actually allocated, the page tables will not be touched. All that happens when you call `mmap` is that an entry is added to the internal table in the Linux kernel that describes your processes memory layout, which takes basically no time. When you attempt to access the memory at one of those locations for the first time though, you will experience a performance hit because your program will page fault due to the mapping for that address not actually existing yet. The kernel will then allocate and map a new page and then return to your program so you can execute the instruction again. After that first access there is no other performance penalties. The unique ID thing may get expensive if you need tons of them, but also since each address within a page is its own unique ID, you get a few thousand unique IDs per syscall, which should cut down on the number of syscalls you have to do. You could also allocate larger blocks of addresses if you wanted too, rather then just a single page.

Wouldn't using those tricks cause significant performance loss due to kernel syscall and page table updates needed for each virtual_alloc call?

by magnat 9y ago

Wouldn't using those tricks cause significant performance loss due to kernel syscall and page table updates needed for each virtual_alloc call?

ZeppelinPL 9y ago

Yeah, using syscall to get uniqueId is kind of controversial...

deleted 9y ago
[deleted]
gizmo 9y ago
You don't do a syscall for _every_ uniqueId, only once every PAGE_SIZE. It's not that expensive. Not every object needs a unique identifier. Objects that need them tend to be larger and have indeterminate lifecycles. Otherwise the overhead of storing a unique id would by itself be egregious, regardless of the process of generating the id. If you can afford to store the id then you can afford the overhead of an occasional syscall.
- amscanne 9y ago
  There are secondary effects that also make this not a great idea. You may wind up slowing leaking vmas (the kernel needs to track what’s been mapped, even if it doesn’t allocate physical pages). This makes future mmap calls and page faults slower. Generating a uniqueID is trivial and super fast (one atomic operation). What’s the benefit here?

jcbeard 9y ago

yes...yes they would.

DSMan195276 9y ago

I don't know for sure for Windows, but for Linux for most of these the answer is no. Until the physical memory is actually allocated, the page tables will not be touched. All that happens when you call `mmap` is that an entry is added to the internal table in the Linux kernel that describes your processes memory layout, which takes basically no time. When you attempt to access the memory at one of those locations for the first time though, you will experience a performance hit because your program will page fault due to the mapping for that address not actually existing yet. The kernel will then allocate and map a new page and then return to your program so you can execute the instruction again. After that first access there is no other performance penalties. The unique ID thing may get expensive if you need tons of them, but also since each address within a page is its own unique ID, you get a few thousand unique IDs per syscall, which should cut down on the number of syscalls you have to do. You could also allocate larger blocks of addresses if you wanted too, rather then just a single page.