Re: [rfc] epoll interface change and glibc bits ...

["Matthew D. Hall" <mhall@free-market.net>]

Davide Libenzi wrote:

>On Mon, 18 Nov 2002, Jakub Jelinek wrote:
>
>  
>
>>That is as bad as unsigned long - it is different between 32-bit and 64-bit
>>ABIs.
>>    
>>
>
>Yeah, you right. I did thin about 32bit and 64bit as two diffferent
>kernel-glibc environment, I did not think about 32-64 ABI compatibility.
>Ouch, adding a 64bit object will double the size of the event structure :(
>
>
>
>- Davide
>
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
>Yeah, you right. I did thin about 32bit and 64bit as two diffferent
>kernel-glibc environment, I did not think about 32-64 ABI compatibility.
>Ouch, adding a 64bit object will double the size of the event structure :(
>  
>
Pros of a 64-bit opaque user pointer:
- Simpler programming for userland.
- Fewer cache misses, because there is no need for accessing part of a 
separate and large fd->pointer table in userland before being able to 
act upon event notification (some implementations can get around this, 
but it's very common practice).

Cons:
- 4 bytes memory wastage on 32-bit platforms per struct.  Note that it 
is not the full 8, because userland needs to have that table of pointers 
anyway.

Notes:
- No memory wastage for nontrivial applications on 64-bit platforms.

Matthew D. Hall