Conversation

Hardware memcpy instruction, except it just traps into the software memcpy implementation

12

10

93

𓃭𓇋𓊃𓄿𓁐

Replying to

you can do this today if you define an interrupt vector specifically for memcpy

2

12

𓃭𓇋𓊃𓄿𓁐

Replying to

and

mov rax, src mov rbx, dst mov rcx, len int 0xFC ; memcpy

1

5

𓃭𓇋𓊃𓄿𓁐

Replying to

and

(interrupt vector for memcpy chosen by fair dice roll, guaranteed to be random)

1

9

𓃭𓇋𓊃𓄿𓁐

Replying to

and

making memcpy even faster by adding a context switch 🧐🧐🧐

1

3

𓃭𓇋𓊃𓄿𓁐

Replying to

and

it occurs to me that the kernel maybe *could* optimize this if src, dst, and len are all page-aligned…🤔🤔🤔

4

11

Replying to

and

Linux kernel moves pages for mremap so it ends up being ridiculously fast especially when transparent huge pages ended up being used. There's MREMAP_DONTUNMAP now to make the original mapping go back to the state of a fresh mapping where zeroed pages will be faulted in on access.

1:19 AM · Oct 17, 2021Twitter Web App

Replying to

and

It was designed to be used in combination with userfaultfd to catch the faults to the source mapping once the old pages are gone. It's an atomic operating and can be used in a compacting GC instead of needing to memory protect the source mapping and copy over the pages manually.

2