The "result" of one async operation is basically a cookie and a result code. Eight or sixteen bytes at most.
s/basically/minimally/
Well, yeah. The patches I sent had:
struct asys_completion {
long return_code;
unsigned long cookie;
};
That's as stupid as it gets.
IMO, before going wacko designing complex shared userspace-kernel result buffers, I think it'd be better measuring the worth-value of the thing ;)
Obviously, yes.The potential win is to be able to have one place to wait for collection from multiple sources. Some of them might want more data per event. They can always indirect out via a cookie pointer, sure, but at insanely high message rates (10gige small messages) one might not want that.
See also: the kevent thread. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Davide Libenzi <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- References:
- [PATCH 0 of 4] Generic AIO by scheduling stacks
- From: Zach Brown <[email protected]>
- [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Zach Brown <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Linus Torvalds <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Linus Torvalds <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Linus Torvalds <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Linus Torvalds <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Zach Brown <[email protected]>
- Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- From: Davide Libenzi <[email protected]>
- [PATCH 0 of 4] Generic AIO by scheduling stacks
- Prev by Date: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
- Next by Date: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
- Previous by thread: Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- Next by thread: Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
- Index(es):
 |