[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44CA613F.9080806@oracle.com>
Date: Fri, 28 Jul 2006 12:10:55 -0700
From: Zach Brown <zach.brown@...cle.com>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
CC: David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC 1/4] kevent: core files.
> So, I'm going to create kevent_create/destroy/control and kevent_get_events()
> Or any better names?
Yeah, that sounds good.
> Some events are impossible to create in userspace (like timer
> notification, which requires timer start and check when timer
> completed).
We're not talking about *creating* events in userspace, we're talking
about checking for their completion events in the ring.
> and get ready), and I do not see how, for exmple, glibc can avoid them
> when user requested POLLIN or similar event for network dataflow?
There are events that can be generated by kernel code paths as the event
completes. Network sockets have the hooks to do this with SIGIO, it's
very natural for the storage completion paths, etc. So that kernel code
would update the ring which userspace could check. AIO does this today.
Userspace would still have to use the syscall to sleep waiting for new
events when the ring is empty.
> According to syscall speed on Linux, last time I checked empty syscall
> took about 100ns on AMD Athlon 3500+.
Oh, sure, but still nice to avoid.
I'm mostly pursuing this because Ulrich seemed so insistent on it in his
paper and talk. I will be very sad if we don't have aggressive glibc
support for this generic event collection interface and so I want very
much to keep him engaged. Ulrich, would you be satisfied if we didn't
have the userspace mapped ring on the first pass and only had a
collection syscall?
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists