Messages in this thread | | | Date | Mon, 18 Nov 2002 14:22:48 -0800 | From | "Matthew D. Hall" <> | Subject | Re: [rfc] epoll interface change and glibc bits ... |
| |
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
- 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/
| |