From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751396AbWGaWBN (ORCPT ); Mon, 31 Jul 2006 18:01:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751389AbWGaWBM (ORCPT ); Mon, 31 Jul 2006 18:01:12 -0400 Received: from dsl027-180-168.sfo1.dsl.speakeasy.net ([216.27.180.168]:29114 "EHLO sunset.davemloft.net") by vger.kernel.org with ESMTP id S1751372AbWGaWBM (ORCPT ); Mon, 31 Jul 2006 18:01:12 -0400 Date: Mon, 31 Jul 2006 15:00:28 -0700 (PDT) Message-Id: <20060731.150028.26276495.davem@davemloft.net> To: johnpol@2ka.mipt.ru Cc: drepper@redhat.com, zach.brown@oracle.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC 1/4] kevent: core files. From: David Miller In-Reply-To: <20060731194143.GA12569@2ka.mipt.ru> References: <44CB8A67.3060801@redhat.com> <20060731103322.GA1898@2ka.mipt.ru> <20060731194143.GA12569@2ka.mipt.ru> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org From: Evgeniy Polyakov Date: Mon, 31 Jul 2006 23:41:43 +0400 > Since kevents are never generated by kernel, but only marked as ready, > length of the main queue performs as flow control, so we can create a > mapped buffer which will have space equal to the main queue length > multiplied by size of the copied to userspace structure plus 16 bits for > the start index of the kernel writing side, i.e. it will store offset > where the oldest event was placed. > > Since queue length is a limited factor and thus no new events can be added > when queue is full, that means that buffer is full too and userspace > must read events. When syscall is called to add new kevent and provided > there offset differs from what kernel stored, that means that all events > from kernel to provided index have been read and new events can be added. > Thus we can even allow read-only mapping. Kernel's index is incremented > modulo queue length. If kevent was removed after it was marked as > ready, it's copy stays in the mapped buffer, but special flag can be > assigned to show that kevent is no longer valid. This sounds reasonable. However we must be mindful that the thread of control trying to add a new event might not be in a position to drain the queue of pending events when the queue is full. Usually he will be trying to add an event in response to handling another event. So we'd have cases like this, assume we start with a full event queue: thread A thread B dequeue event aha, new connection accept() register new kevent queue is now full again add kevent on new connection At this point thread A doesn't have very many options when the kevent add fails. You cannot force this thread to read more events, since he may not be in a state where he is easily able to do so.