|
About
TODO
Blog
RSS
Old blog
Projects
Gallery
Notes
Sat, 19 Apr 2008
hbukittbd: Andrew Morton proposes new userspace/kernelspace interface.
This is may be our third high-bandwidth user/kernel interface to transport bulk data ("hbukittbd") which was implemented because its predecessors weren't quite right. In a year or two's time someone else will need a hbukittbd and will find that the existing three aren't quite right and will give us another one. One day we need to stop doing this ;)Just for the reference, I've filled it under kevent tag :) /devel/kevent :: Link / Comments (0) Thu, 07 Feb 2008
Memory notification events.
/devel/kevent :: Link / Comments (0) Tue, 14 Aug 2007
Kevent has been removed from kernel summit agenda.
/devel/kevent :: Link / Comments (0) Tue, 15 May 2007
Kevent/eventfd/pollfs discussion thread. Monolitic and interface-centric solutions, or better, solutions in search of a problemgetting into account that each kevent kernel user is about 300 lines of code including comments and its registration is completely plugable even in run-time and its memory overhead is several times less. I'm sitting and wondering... And to start the day, two citations from that thread: Yes, of course. If we're heading to yet-another monolitic interface, we're heading with no valid reasons given if other than some handwaving. While there are quite a few (modularity, compatibilty, plus the other ones that came in my mind and that I explained in the way-too-many emails) to back a file-based approach.... That's my point. I think we ultimately have to have something like kevent and then all this *fd() work is unnecessary and just adds code to the kernel which has to be kept around and which might hinder further work in this area.But actually who cares? I've just looked into mainline git tree and found, that the whole eventfd patchset is already committed into the tree. Personally I completely do not care. Actually my massive kevent spambombing resulted in some changes in people's minds - I see a lot of kernel projects started to add 'takeN' to theirs short descriptions to show iteration number, which I did not see before. /devel/kevent :: Link / Comments (0) Thu, 10 May 2007
Kevent strikes back? /devel/kevent :: Link / Comments (0) Fri, 16 Mar 2007
Asyncfd by Davide Libenzi got ring buffer.
For example I do not see how to solve second problem from above list, since kevent has (had) own queue of events, which were copied from the queue when userspace updated indexes, so if userspace ring is full, they would not be lost, but existing mechanism does not have such a queue at all, events are just blindly copied and thus can be lost when ring is full. First problem must be solved too to support tricky usage (as Davide mentioned in patch description, USB calls might enp up calling it from interrupt context). One of the problems Davide solves either by using locked userspace memory (which is a big no-no), or by using kernel buffers and read(), which is unconvenient and just
breaks the whole idea of ring buffer - having multiple events in userspace without
additional (only waiting) syscalls and having syscalls as thread cancellation points
without additional structures shared between threads.Timerfd implementation will likely rise the same questions from Ulrich Drepper as my kevent timers - they are not needed, instead POSIX timers support should be extended (although I always provided two patches - for POSIX timers and own API, maybe Davide will use both too). But POSIX timer events become ready in softirq context, so it is impossible to use above ring buffer implementation for them. Timerfd code also uses long type in structures shared between userspace and kernelspace,
which does not work on x86_64 when userspace is 32bit.Yes, I know, I'm a bastard moron, since I write only bad things in my blog, but hey, I was not in Cc: list :) Actually I'm glad people started to work in that area after kevent, that means that my ideas were correct and eventually Linux will adopt a good solution for that problems. I think Davide will resolve all issues quickly. /devel/kevent :: Link / Comments (0) Sun, 04 Mar 2007
Kevent. /devel/kevent :: Link / Comments (0) Fri, 02 Mar 2007
How things can endup with some trivial initial misunderstanding. [ND] (you are never ever wrong, and if you are proven wrong on topic A you claim it is an irrelevant topic (without even admitting you were wrong about it) and you point to topic B claiming it's the /real/ topic you talked about all along. And along the way you are slandering other projects like epoll and threadlets, distorting the discussion. This kind of keep-the-ball-moving discussion style is effective in politics but IMO it's a waste of time when developing a kernel.)Sigh, we started very interesting topic, but ended up with some personal insults and drawing things people never talked about and even remotely based assumptions on - and all just because of some trivial misunderstanding of the simplest context. That's pity, but well, if things has moved to that point, fuck them, there will be tons of others. It seems I broke possible good relations with some very interesting kernel hackers, but I never wanted to do any personal or project insults for my own advertisement. If people can not (or do not) understand that, then, well, let's just move further. /devel/kevent :: Link / Comments (0)
Quotation of the week. [ND] sure, if we debate its virtualization driven market penetration via self promoting technologies that also drive customer satisfaction, then we'll be able to increase shareholder value by improving the user experience and we'll also succeed in turning this vision into a supply/demand marketplace. Or not?I'm going to write that mantra in some piece of the memory. /devel/kevent :: Link / Comments (0) Tue, 27 Feb 2007
All fights about kevent vs. threadlet are over. [ND]
/devel/kevent :: Link / Comments (0) Mon, 26 Feb 2007
Kevent vs. epoll vs. threadlet on VIA EPIA. kevent: 849.72 epoll: 538.16 threadlet: # gcc ./evserver_epoll_threadlet.c -o ./evserver_epoll_threadlet In file included from ./evserver_epoll_threadlet.c:30: ./threadlet.h: In function threadlet_exec: ./threadlet.h:46: error: can't find a register in class GENERAL_REGS while reloading asmThat particular threadlet asm optimization does not work. /devel/kevent :: Link / Comments (0)
How to get attention to your project (secret plans upto now). Kevent and Ingo's threadlets. Scholastic masturbation about events and execution context. [ND]
And it is challenging! Heh, things has ended up with complete fight against kevent. Ingo Molnar wrote: conclusion: currently i dont see a compelling need for the kevents subsystem. epoll is a pretty nice API and it covers most of the event sources and nicely builds upon our existing poll() infrastructure.I need to say, that I have not ran any tests yet, since my Intel Core2 test machine has x86_64 distro, and I can not download new distro du to bandwidth limitation, and my via epia machine still compiles a tree... So, right now I'm cooking up a tree which includes both kevent and syslet/threadlet patches to test kevent/epoll/threadlet. I will do it on couple of my test machines: via epia (1ghz, 256mb of ram, 100mbit ethernet) and Intel Core2 CPU (2.40GHz, 2gb of ram, gigabit ethernet). Client will be ' ab' on my desktop Intel Core Duo 3.7 Ghz
test machine with gigabit ethernet.So, stay tuned - if I will complete all setup before I go climbing (and wine will not end), I will post all results here (even if kevent will shitassly suck). Meanwhile on x86_64 several runs of the same ab -c8000 -n80000 http://192.168.0.48/ kevent 8447.78 5248.45 4792.66 4689.78 4978.08 5207.60 epoll 4572.20 5024.89 4580.57 4800.19 4708.29Even in median kevent is faster than epoll. And some times it is about two times faster. /devel/kevent :: Link / Comments (0) Sat, 24 Feb 2007
New lighttpd patch. /devel/kevent :: Link / Comments (0) Thu, 22 Feb 2007
New kevent 'take37' release. [ND].
If you are somehow related to kevent development, please do not perform any steps about this post. Thank you. A bit of history of the project. I developed it first to create asynchronous network IO as a challenge request from Stephen Hemminger. Back in previous winter I created both kevent as a generic event delivery mechanism and network AIO too. It worked, it showed noticeble perfomance and usability win. I tried to push it upstream but never got a response. Later previous year David Miller made a good kick for kevent and I started to push it upstrem again. There were number of changes aimed to improve performance, extend feature list and eventually we have subsystem which indeed can be called as generic event handling mechanism. Set of features it can work with includes file descriptor events - the same as in usual poll()/select()
(there is a patch which implements epoll() over kevent),
special high-performance socket and pipe notifications,
possibility to get timer expiration events, POSIX timers
and signal notifications, possibility to have any
private userspace notifications and eventually even network AIO
(sendfile(), open+sendfile()+close()).I ported libevent and lighttpd to kevent. But I'm continuously getting trouble obtaining feedback from kernel developers despite a huge support from several core kernel hackers and I want to thank them and a lot of other people who helped to develop that subsystem. I do not care much about kevent inclusion - I hacked it not for that but for process, but such hinged situation takes a lot of time to throw code and words again and again into blackhole. For the my last kick for Andrew Morton and Ulrich Drepper to include kevent I got a response about the fact that it needs some more review and some more comments. So, -rc1 is out and I've sent the latest kevent release. If there will be no feedback I will not continue to push it upstream. I will continue to support it on per kernel release basis like I do for many years for acrypto (asynchronous crypto layer). It is not too big work to maintain that, but pushing it into the rock wall is a bit uninteresting and actually stupid time spending. Please do not kick someone to get a review or something like that - if people do not want it right now, there is no need to force them - eventually it can end up with some better system (let's see how acrypto work resulted (or maybe not) in a upcoming async crypto changes in Linux crypto stack) from some other kernel hacker. As I expect to get some free time after -rc1 is out, I will continue to work on my interesting projects, the nearest ones are M:N theading model and netchannels trie patch to replace socket hash tables. It looks like it is time to start new generation filesystem implementation too. /devel/kevent :: Link / Comments (0)
Thinking more on syslets/threadlets and kevent. [ND] /devel/kevent :: Link / Comments (0)
New syslet/threadlet release by Ingo Molnar.[ND]
/devel/kevent/aio :: Link / Comments (0) Sat, 17 Feb 2007
Kevent has a git tree now. $ git clone http://tservice.net.ru/~s0mbre/archive/kevent/kevent.git/ ./Here one can find steps needed to create public git repo (which is not that trivial step and it is not described in popular git tutorials). /devel/kevent :: Link / Comments (0)
Linus and GNOME, kernel and kevent. I've sent out patches. The code is actually _cleaner_ after my patches, and the end result is more capable. We'll see what happens.Doesn't it sound too similar to kevent mails? Damn yes. /devel/kevent :: Link / Comments (0) Fri, 16 Feb 2007
Syslet cancellation. What about the busy_async_threads list becoming a hash/rb_tree indexed by syslet_atom ptr. A cancel would lookup the thread and send a signal (of course, signal handling of the async threads should be set properly)?I tired to repeat, that if AIO enters async path, then it becomes a real event which can be waited for. And it is done through kevent, which supports kevent cancellation already. It also supports waiting for events, reading them through kevent queue and ring buffer. Ring buffer is implemented in a userspace - guess, what will be added in v3 release of the syslets? /devel/kevent :: Link / Comments (0)
Syslets and events. We have kaio that is centered around block drivers - then we have epoll that works best with networking, and inotify that deals with some (but not all) VFS events - but neither supports every IO and event disciple well, at once.I'm disappointed. I would understand if it was written by Linus Torvalds, but not Ingo... /devel/kevent :: Link / Comments (0) Tue, 13 Feb 2007
Kevent is not closed. /devel/kevent :: Link / Comments (0) Mon, 12 Feb 2007
New kevent '
-[take35 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()). +[take36 10/10] kevent: Kevent based generic AIO. -Kevent based AIO (aio_sendfile()/aio_sendfile_path()). +Kevent based generic AIO. + +This patch only implements network AIO, which is _COMPLETELY_ +impossible and broken in _ANY_ micro-thread design. For details +and test consider following link: +http://tservice.net.ru/~s0mbre/blog/2007/02/10#2007_02_10 + +Designing AIO without network in mind can only be result of heavy hang-over. + +Kevent AIO is implemented as state machine. +There is a patch which implements async open/send_header/sendfile/close.Changes in main description: -[take35 0/10] kevent: Generic event handling mechanism. +[take36 0/10] kevent: Generic event handling mechanism [new description text for generic AIO]. -Generic event handling mechanism. +Generic event handling mechanism [new description text for generic AIO]. + + [ Consider reading at least introduction texts for patches ] Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and + + It can serve as a storage for different AIO models as well - in case + syscall or other request is ready immediately kevent returns that event + in submission point. + Number of comments dropped to zero several releases ago - + it is a sign that API, design and implementation are perfect. + Consider for inclusion.I also asked Andrew Morton (again) about inclusion/declining plans. If that will be put into void again, I think it is time to close project. /devel/kevent :: Link / Comments (0) Sun, 11 Feb 2007
Linus on AIO. Limitations of the proposal. Practical example of weakness. > Will you create a thread every time tcp_sendmsg() hits the send queue > limits?I.e. we design Asynchronous IO, which is already limited to not be used with network? I.e. AIO can not be used in anything connected to the network, since even if disc read/write will be asynchronous, sending will block and thus we just lose all possible advantages. Continue: There's a reason why a lot of UNIX system calls are blocking: they just don't make sense as event models, because there is no sensible half-way point that you can keep track of (filename lookup is the most common example).Linus - blocking IS waiting for an event, which will remove that block. Linux even uses wait_event_*() calls - don't you think that name has some sence?Filename lookup is just an inode reading from disk - when it is done, filename is ready, that is an event. And actually no one uses async filename lookup - people use open()
syscall, which is perfectly eventable - block-removal event is readines of the opened file
descriptor - it is even used in kevent AIO (surprise?) as a part of the async sendfile transfer
state machine (but I must admit, that opening always happens in async mode as part of the
state machine, so it will lose some ticks if things are perfectly in the cache,
but practice shows
that async sendfile is faster).In another mail Linus continues to burn things out: You use the AIO stuff for things that you *expect* to be almost instantaneous. Even if you actually start ten thousand IO's in one go, and they all do IO, you would hopefully expect that the first ones start completingn before you've even submitted them all. If that's not true, then you'd just be better off using epoll.I.e. we should not use AIO for the case, when request really blocks, only when it is synchronous and maybe sometimes block. Linus, direct IO (used by databases) blocks all the time, sync IO blocks all the time, network blocks, pipes block, readahead blocks - only the simplest case of reading from VFS cache does not block. And eventually Linus proposes waiting for AIO events: for (;;) {
async(epoll); /* wait for networking events */
async_wait(); /* wait for epoll _or_ any of the outstanding file IO events */
handle_completed_events();
}
Linus - you have just introduced a waiting for AIO events - i.e. new type of events,
which are supposed to wrap async completions. And since every async syscall is that new
event, we can wait for them in userspace loop.You do not know, but kevent is supposed to wait on every possibly type of events - you do not need to wrap sync-events-waiting calls (like epoll()) into async helper
and then wait for that - just register it with kevents where you are currently forks in patchset.And to draw the line: AIO by micro-threads is not even supposed to work in environments where it will block all the time (like network or direct IO), instead in blocking environments events should be used, since they are much more scalable. Micro-thread AIO sucks even in reading from file - practice example: if file is happend on bad block, reading will block for too long (seconds!), and system can be just killed with rescheduling when there are a lot of threads waiting for read completion on that blocks. And to finally kill such design, here is another test I created. Consider a directory with high number of inner dirs and files (hundreds), theirs total size is 3 times smaller than amount of RAM (1gb vs. 300 Mb) and several applications which run and randomly copy data from one file to another. I've put several printks in __lock_page() (i.e. when requesting
application blocks and thus new thread would be created) and watch a nice picture
when upto hundred of blocks happend per second (and that is just for the case, when size
of the test dir is 3 times smaller than RAM, what will happen when size of the dir
will be more than amount of RAM I even do not want to imagine):
printk: 84 messages suppressed. __lock_page: aio_new_thread: 6650. printk: 118 messages suppressed. __lock_page: aio_new_thread: 6769. Conclusion: 'f toppku', i.e. into the furnace. /devel/kevent/aio :: Link / Comments (0) Sat, 10 Feb 2007
Test which shows how broken is thread-like AIO design. tcp_sendmsg: sock: ffff810038e57900, wait: 562. tcp_sendmsg: sock: ffff810038e57340, wait: 563. tcp_sendmsg: sock: ffff810038e56d80, wait: 564. tcp_sendmsg: sock: ffff810038e567c0, wait: 565. tcp_sendmsg: sock: ffff810038e56200, wait: 566. printk: 20458 messages suppressed. tcp_sendmsg: sock: ffff81003363d300, wait: 21025.and the like... That was a simple couple of seconds test run of ab benchmark
against 2.6.20 kernel with lighttpd web server - about 4k connections per second,
80k connections total, trivial index page (got from debian installer) on athlon64 with 1gb of ram
connected over 1gbit link.And during that simple test system would created 21k threads? No way, it is just broken design. It is wrong. So, read my lips - ev-e-ry-thing con-nec-ted to the net-work sle-eps. Linus, if you read this (although I doubt), please, do not make terrible mistake. Do not include kevent, if you do not want, but please think about above test before it is too late. /devel/kevent/aio :: Link / Comments (0) Wed, 07 Feb 2007
New kevent slogan - 'kevent can do everything you ever thought of. Completely.'
/devel/kevent :: Link / Comments (0)
Continue on AIO thread and kevents. Don't be silly. AIO isn't an event. AIO is an *action*.It is up to AIO interface - it can request completion event after it has checked that system blocks, if it can not check that in advance it still can perfectly fine use kevents, since kevents are not blocked and returned immediately (if special flag KEVENT_REQ_ALWAYS_QUEUE is not set) in case of underlying subsystem does not block and can provide data immediately. Setup for kevent is a cache allocation and queueing into the binary tree, so one can calculate how fast it is - it is just bloody faster than process creation or rescheduling. Actually that is silly - if that would have anyhow similar performance costs for thread creation and kevent creation, no one ever used polling - people would use real threads per event. Fibril allocation (and it happens always) is slower than kevent one, and in case of block - price becomes just too expensive. Yeah, in 1% of all cases it will block, and you'll want to wait for them. Maybe the kevent queue works then, but if it needs any more setup than the nonblocking case, that's a big no.Linus, your never ever read what I posted in all kevent related threads - shame on you, since it was you who appreciated similar design (well, it was created by you, but it was much simpler and feature free) several years ago - but emoutions must go away - kevent does not differentiate between blocking and non-blocking mode until special flags are set - in the usual case kevent is allocated, its fields are filled and it is queued into the tree. Eric Dumazet wrote: It seems to me that kevent was designed to handle many events sources on a single endpoint, like epoll (but with different internals). Typical load of thousand of sockets/pipes providers glued into one queue.Let me clarify what are event sources and how events are delivered to userspace - it is possible to have tons of event sources (timers, sockets, pipes, fibrils, anything) in the same kevent tree, but they are posted back to userspace one-by-one through ring buffer or through syscall to save order (one can have multiple threads reading the same ring buffer though). If there will not be enormous number of fibrils per process, then it is fine - theirs number does not play any significant role. To get events through kevent queue fd loopkup is needed - but it is much-much-much less costly than rescheduling and thus fibril completion. If there are multiple threads doing completion processing, they should use ring buffer - it was created exacly for that purpose, so kevent queue will not have a lot of lookups per event at all and will not have simultaneous access to atomic operation too - think about compare and exchange operation in modern CPUs, which Ulrich wanted to implement in threads reading kevent ring buffer. Kent Overstreet wrote: An app can have a bunch of cheap, fast user space threads servicing whatever; as they run, they can push their system calls onto a global stack. When no more can run, it does a giant asys_submit (something similar to io_submit), then the io_getevents equivilant, running the user threads that had their syscalls complete.That is exactly how kevents work - no need to invent new wheel. And that is, btw, how AIO sendfile works (except underlying state machine) - it gathers file descriptor or path, socket and length/offset parameters, combine a private structure and creates a kevent, which will be completed either immediately if sending does not block, or will return error and state machine will handle that (in case file descriptor or socket is in non-blocking mode), or handling thread blocks and is scheduled away, so new one can pickup next request. The whole sub-thread started after this message is specilating about how we could invent new things, which happend to be implemented yar ago and called kevent. Hey, it is already done. Davide Libenzi wrote: Note that it's not a trivial tasks to extract a long enough level of parallelism, that would make you feel pain in having to walk through the submission array. Think about the trivial web server case. Remote HTTP client asks one page, and you may think to batch a few ops together (like a stat, open, send headers, and sendfile for example), but those cannot be vectored since they have to complete in order. The stat would even trigger different response to the HTTP client. You need the open() fd to submit the send-headers and sendfile.Really? And how do you think it can be solved? by issuing tons of async IO? No, it is way to faster to be solved as a state machine suggested by Ingo Molnar and me - kevent AIO works that way, AIO sendfile was implemented that way, and it was proven that state machine (file path and header are provided into the call, it internally opens file, sends its content (populates pages into VFS cache if needed), and closes file) works faster even for pages in VFS cache (which are not supposed to block). Who is going to eat own's hat? Possible AIO design: /devel/kevent :: Link / Comments (0) Tue, 06 Feb 2007
Linus Torvalds again. Also, quite frankly, I tend to find Uli over-designs things.Linus, do not see for design, watch the fucking implementation, which is there for too long already, and was created way long before Ulrich created his design, which in first edition was a subset of kevent (later were added ring buffer and possible thread id). One just needs to patch and run - it is already done. Totally and completely. Another sentence: We want less code. The whole (and really, the _only_) point of the fibrils, at least as far as I'm concerned, is to *not* have special code for aio_read/write/whatever.I tend to agree here, but Linus, you are missing the main problem - if more code means faster processing, it is better, so fibril rescheduling just can not compete there with specially written AIO calls - like C written copy can not compete with asm one - fibrils do not scale with SMP, rescheduling of the system with 10k fibrils is impossible, task allocation (even smaller task) is slow - there are too many things where fibrils suck. /devel/kevent :: Link / Comments (0)
Continue on fibril AIO thread. This time Linus Torvalds. But if you want to, we could have a *separate* "convert async cookie to fd" so that you can poll for it, or something. I doubt very many people want to do that. It would tend to simply be nicer to doLinus, wake up, it is done already. I post a new patchset each week for the last several months (started more than a year ago), which implemented that already.async(poll); async(waitpid); async(.. wait foranything else ..)followed by await_for_async();That's just a much NICER approach, I would argue. And it automatically and very naturally solves the "wait for different kinds of events" question, in a way that "poll()" never did (except by turning all events into file descriptors or signals). Linus even says magical words: wait for different kinds of events, which is written in every mail about kevent I sent for the last year. Kevent already allows to wait on different kinds of events - from file descriptors down to signals or timers. On any kind of events. Trivially. /devel/kevent :: Link / Comments (0)
Is kevent perfect? I'd be quiet if there were some well formulated objections to his work being posted, but people are posting nothing. So either it's a perfect API or people aren't giving it the attention and consideration it deserves. Obviously, kevent is perfect! /devel/kevent :: Link / Comments (0)
Interesting, where does Oracle get that? As Joel mentioned earlier, from an Oracle perspective, one of the key things we are looking for is a nice clean *common* wait point. We don't really care whether this common wait point is the old libaio:async-poll, epoll, or "wait_for_async". And if "wait_for_async" has the added benefit of scaling, all the better.Scot, you did your homework quite bad - just chek linux-kernel@ and read kevent mails I post about weekly - everything you described above is implemented about a year ago already - and as a bonus it has a lot of additional high-performance features, interfaces and usage cases added later. /devel/kevent :: Link / Comments (0)
Continue fibril AIO discussion. Zab's async syscall interface is a pretty simple one. It accepts the syscall number, the parameters for the syscall, and a cookie. It returns a syscall result code, and your cookie... So, what's wrong with all that people? Kevent's structure does gets as parameters event type and id - which is exactly syscall number, there is also a user's pointer, which can be used as cookie or as a pointer to data, where syscall parameters live. But thinking some more on it, it becomes completely wrong discussion - one can use any userspace interface he/she likes - kevent is event handling mechanism, it is used for AIO completions, it is used in POSIX timers - fibril AIO (which design I'm not agree with) can use kevent as a queue, which will return all its results - just see how it is implemented in kevent AIO or POSIX timers and adopt it to fibrils, or at least read documentation or mails annotations, which describe kevent usage cases. What Davide Libenzi is wrong about in his mind, is the fact, that neither kevent, nor poll()/epoll() are supposed to be an AIO mechanism - they were
created to deliver events - AIO completion is one of the events, which can be perfectly
delivered by kevent and poll()/epoll(), the latter requires heavy
file->bindings, while the former does not at all.Kevent AIO or fibril AIO, or FSAIO - they are different mechanisms of doing AIO, but all of them can use kevent to deliver its own events like completion or errors. /devel/kevent :: Link / Comments (0) Mon, 05 Feb 2007
More comments on fibrills AIO. Being able to wait on that with file->poll() obviously requires juggling file-> associations which sounds like more weight than we might want. Or it'd be optional and we'd get more moving parts and divergent paths to test. Davide Libenzi wrote: Yes, no need for the above. We can just host a poll/epoll in an async() operation, and demultiplex once that gets ready. If you follow kevent blog and know how it works, you will understand, why I want to crack my head against the wall. /devel/kevent :: Link / Comments (0)
Kevent compilation is broken - patch has been released. /devel/kevent :: Link / Comments (0) Sun, 04 Feb 2007One of the big problems today is that you can either sleep for your I/O in(c) Oracle. Original (thread about fibrils and AIO by scheduling stcks). What can I say - NIH syndrome is washing brains (I must say I have it too), or people just too lazy to bother to read something created by others. /devel/kevent/aio :: Link / Comments (0) Sat, 03 Feb 2007
Fibrills and threads. /devel/kevent :: Link / Comments (0)
Fibrills AIO, kevent AIO and Ingo's ideas. /devel/kevent :: Link / Comments (0) Fri, 02 Feb 2007
I could not resist. New kevent feature - async file open. /devel/kevent :: Link / Comments (0) Thu, 01 Feb 2007
New kevent 'take35' release.
Andrew suggested that someone performed a line-by-line review of the patchset (it grew to 208 Kb after most major features were implemented) and someone to provide a diff between current implementation and what Ulrich Drepper has in mind regarding this project. Unfortunately this requires either mind-reading machine, or some feedback from Ulrich. Last mail from him about kevent was related to 25 release, which implemented most of the changes he wanted, although I do not like them, but it was at least some progress. The rest of the differences are signal mask in syscalls, but nature of kevent signal delivering does not require it, since mask of pending signals is not updated if special flag is set, and exceeded functionality (like hrtimers accessible through kevent interface and as POSIX addon). But as practice shows, it is not enough to convince anyone, since people with whom I argued about, are not going to listen and understand why and how kevent works. But I will try. Again. As for current kevent status, it is somewhere in feature-freeze state, awaiting (maybe forever) for decision. /devel/kevent :: Link / Comments (0) Thu, 25 Jan 2007
New kevent version 'take34' has been released. /devel/kevent :: Link / Comments (0) Fri, 19 Jan 2007
Kevent feature request for /devel/kevent :: Link / Comments (0) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||