Zero-copy realizuje się kilkoma komplementarnymi mechanizmami: (1) mmap() mapuje plik lub region pamięci bezpośrednio do przestrzeni adresowej procesu, dzięki czemu nie trzeba kopiować danych do osobnego bufora; (2) sendfile()/splice() przenoszą dane między deskryptorami plików w całości wewnątrz jądra, omijając bufor przestrzeni użytkownika; (3) pamięć współdzielona (shared memory) pozwala wielu procesom odczytywać ten sam region bez kopiowania — wymienia się jedynie wskaźnik lub uchwyt; (4) DMA (Direct Memory Access) pozwala kontrolerowi sprzętowemu przenieść dane między urządzeniem a pamięcią bez udziału CPU; (5) zunifikowana pamięć CPU–GPU oraz przekazywanie wskaźników eliminują kopie między hostem a akceleratorem. We wszystkich wariantach zamiast fizycznego kopiowania bajtów przekazuje się odwołanie do danych (wskaźnik, offset, uchwyt), a poprawność zapewnia zarządzanie własnością bufora i synchronizacja dostępu.
Tradycyjny transfer danych wielokrotnie kopiuje te same bajty między buforami (jądro↔przestrzeń użytkownika, proces↔proces, CPU↔GPU), zużywając cykle CPU, przepustowość pamięci i powodując przełączenia kontekstu. Przy dużych wolumenach danych (klatki z kamer, strumienie sieciowe, tensory) te redundantne kopie stają się wąskim gardłem wydajności i źródłem opóźnień.
Odwzorowanie pliku lub regionu pamięci bezpośrednio do przestrzeni adresowej procesu, eliminujące kopię do osobnego bufora użytkownika.
Oficjalna
Wywołania systemowe przenoszące dane między deskryptorami (np. plik→gniazdo) w całości wewnątrz jądra, z pominięciem bufora przestrzeni użytkownika.
Oficjalna
Region pamięci dostępny dla wielu procesów; zamiast kopiowania wymienia się wskaźnik/uchwyt. Podstawa zero-copy w middleware IPC (np. iceoryx).
Oficjalna
Sprzętowy transfer danych między urządzeniem (NIC, dysk, GPU) a pamięcią bez udziału CPU; obejmuje warianty jak RDMA i GPUDirect.
Oficjalna
Wspólna przestrzeń adresowa CPU i GPU umożliwiająca przekazywanie danych przez wskaźnik zamiast kopii host↔device; kluczowa dla potoków GPU (np. Isaac ROS).
Oficjalna
Zwolnienie lub nadpisanie współdzielonego bufora zanim odbiorca skończy go czytać prowadzi do błędów use-after-free i uszkodzenia danych.
Brak synchronizacji przy współdzielonym regionie może dać niespójne lub częściowo zapisane dane.
mmap i DMA wymagają wyrównania do granic stron; niespełnienie tego psuje mapowanie lub wymusza kopię.
Dane w pamięci współdzielonej są widoczne dla innych procesów mających do niej dostęp, co zwiększa powierzchnię ataku.
Gdy warstwa transportu nie wspiera zero-copy, system może po cichu wrócić do kopiowania, niwecząc oczekiwane zyski wydajności.
Wywołanie sendfile() pojawiło się w Linux 2.2, umożliwiając transfer plik→gniazdo bez kopiowania danych do przestrzeni użytkownika.
splice() uogólnił zero-copy na dowolne pary deskryptorów, przenosząc dane przez potok w jądrze.
Dodano zero-copy przy wysyłaniu danych sieciowych bezpośrednio z buforów przestrzeni użytkownika.
ROS 2 (Eloquent) wprowadził API loaned messages, umożliwiając zero-copy przez pamięć współdzieloną w DDS (np. Eclipse iceoryx, RTI Connext DDS Micro).
Type adaptation (REP-2007) i type negotiation (REP-2009) umożliwiły zero-copy transport danych GPU między węzłami ROS 2.
Isaac ROS przeniósł zero-copy GPU na natywne wiadomości ROS 2 z polami rosidl::Buffer i backendem buforów CUDA.
Złożoność czasowa: O(1) kopii CPU (vs. O(n)). Złożoność przestrzenna: O(1) dodatkowej pamięci buforowej.
Kto jest właścicielem współdzielonego bufora i kiedy można go bezpiecznie zwolnić (model loan/return).
Sposób zapobiegania wyścigom czytelnik–pisarz w pamięci współdzielonej (mutex, bariery, wersjonowanie).
Wymagane wyrównanie do granic stron dla mmap i DMA.
Zachowanie, gdy warstwa transportu nie wspiera zero-copy (np. ROS_DISABLE_LOANED_MESSAGES → fallback do kopii).
Zero-copy to technika systemowa/programowa działająca na dowolnej platformie z MMU i wsparciem systemu operacyjnego.
Zunifikowana pamięć CPU–GPU oraz GPUDirect pozwalają przenosić tensory między hostem a GPU bez kopii, co przyspiesza potoki inferencji i wizji.
