[Linux/C++] mmap flags en gedrag

[Olaf van der Spek]

In een netwerk applicatie (BitTorrent) wil ik memory mapping gebruiken, onder andere om onnodige data copying te vermijden.

De mmap man page legt echter niet zoveel uit.
Bijvoorbeeld, wat doen de de volgende flags precies?

code:

MAP_POPULATE (since Linux 2.5.46)
  Populate (prefault) pagetables.

MAP_NONBLOCK (since Linux 2.5.46)
  Do not block on IO.

En als ik bijvoorbeeld send() gebruik om een deel van een mmaped file te verzenden, wat gebeurd er dan bij een read error?

Google wil in dit geval ook niet echt helpen.

[MSalters]

"Prefaulting" is vermoedelijk het in RAM mappen van de file als onderdeel van de mmap call. Normaal gesproken gebeurt dat pas op een fault, dus als je de geheugenrange probeert te gebruiken terwijl die nog niet in RAM is geladen.

[Olaf van der Spek]

MSalters schreef op dinsdag 09 augustus 2005 @ 15:54:
"Prefaulting" is vermoedelijk het in RAM mappen van de file als onderdeel van de mmap call. Normaal gesproken gebeurt dat pas op een fault, dus als je de geheugenrange probeert te gebruiken terwijl die nog niet in RAM is geladen.

Daar dacht ik ook aan, maar is dat dan blocking of non-blocking? En dan zou populating pages logischer zijn dan populating pagetables.

[MSalters]

Use the source, Luke.

In het algemeen heb je bij non-blocking operaties een notificatiemechanisme. De afwezigheid daarvan suggereert dus een blocking call.

[Verwijderd]

Hij maakt dus eerst je page TABLES aan (de tabel die de cpu gebuikt om je logische adressen om te zetten naar fysieke adressen). Dus niet de daadwerkelijk gegevens. Dit is dus blocking maar geen disk io. Ik zou het voor jou applicatie niet gebruiken, het is meer iets voor realtime dingen.

send zal wel falen met EFAULT ofzo, misschien ook met een signal, moet je gewoon maar proberen dan, maar NONBLOCK is denk ik ook niet interesant (weinig extra resultaat voor veel extra code)

[Olaf van der Spek]

Verwijderd schreef op dinsdag 09 augustus 2005 @ 22:03:
Hij maakt dus eerst je page TABLES aan (de tabel die de cpu gebuikt om je logische adressen om te zetten naar fysieke adressen). Dus niet de daadwerkelijk gegevens. Dit is dus blocking maar geen disk io. Ik zou het voor jou applicatie niet gebruiken, het is meer iets voor realtime dingen.

Waarom niet? Als ik weet dat bepaalde data nodig is, is het toch handig als de kernel dat zo vroeg mogelijk weet?

send zal wel falen met EFAULT ofzo, misschien ook met een signal, moet je gewoon maar proberen dan, maar NONBLOCK is denk ik ook niet interesant (weinig extra resultaat voor veel extra code)

Non-blocking sends heb ik al. Nu alleen nog non-blocking reads. Een ander voordeel van non-blocking reads is dat de kernel command-reordering kan toepassen.

Maar als de send in het midden faalt is dat ook niet zo handig.

[ Voor 7% gewijzigd door Olaf van der Spek op 09-08-2005 22:56 ]

[igmar]

OlafvdSpek schreef op dinsdag 09 augustus 2005 @ 15:46:
Bijvoorbeeld, wat doen de de volgende flags precies?

code:

MAP_POPULATE (since Linux 2.5.46)
  Populate (prefault) pagetables.

Deze flag zorgt ervoor dat de pagetables voor de mapping meteen worden opgezet, in plaats van wanneer er een pagefault optreed.

MAP_NONBLOCK (since Linux 2.5.46)
Do not block on IO.[/code]En als ik bijvoorbeeld send() gebruik om een deel van een mmaped file te verzenden, wat gebeurd er dan bij een read error?

Ik vermoed dat dit betekend dat een indien een syscall op data in een page er toe leid dat er op disk OP gewacht moet worden, de syscall EAGAIN retourneerd. Maar dat zul je denk ik even moeten testen.

Google wil in dit geval ook niet echt helpen.

Ik kan me niet voorstellen dat je ze nodig gaat hebben eerlijk gezegd. Portable zijn ze zowiezo niet, en d'r is ook zoiets als async IO voor diskaccess.

[Olaf van der Spek]

igmar schreef op woensdag 10 augustus 2005 @ 08:56:
Ik kan me niet voorstellen dat je ze nodig gaat hebben eerlijk gezegd. Portable zijn ze zowiezo niet, en d'r is ook zoiets als async IO voor diskaccess.

Maar met async IO heb je toch altijd nog een extra copy van kernel naar user memory?

[igmar]

OlafvdSpek schreef op woensdag 10 augustus 2005 @ 09:19:
[...]

Maar met async IO heb je toch altijd nog een extra copy van kernel naar user memory?

AIO kun je AFAIK ook doen op mmap()'ed pages. Het nadeel van AIO momenteel is dat het niet werkt op sockets, maar kwa snelheid verschilt epoll() niet veel van AIO.

[Olaf van der Spek]

igmar schreef op woensdag 10 augustus 2005 @ 09:43:
AIO kun je AFAIK ook doen op mmap()'ed pages. Het nadeel van AIO momenteel is dat het niet werkt op sockets, maar kwa snelheid verschilt epoll() niet veel van AIO.

Maar waarom zou je zowel AIO als mmap gebruiken? Als je een file mmaped heb je toch geen AIO meer nodig?