LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Hans Henrik Happe <hhh@imada.sdu.dk>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	Ulrich Drepper <drepper@gmail.com>,
	lkml <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Ulrich Drepper <drepper@redhat.com>,
	Andrew Morton <akpm@osdl.org>, netdev <netdev@vger.kernel.org>,
	Zach Brown <zach.brown@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	Chase Venters <chase.venters@clientec.com>,
	Johann Borck <johann.borck@densedata.com>
Subject: Re: [take19 1/4] kevent: Core files.
Date: Thu, 5 Oct 2006 16:01:19 +0200	[thread overview]
Message-ID: <200610051601.20701.hhh@imada.sdu.dk> (raw)
In-Reply-To: <20061005102106.GE1015@2ka.mipt.ru>

On Thursday 05 October 2006 12:21, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet (dada1@cosmosbay.com) 
wrote:
> > On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
> > 
> > > Well, it is possible to create /sys/proc entry for that, and even now
> > > userspace can grow mapping ring until it is forbiden by kernel, which
> > > means limit is reached.
> > 
> > No need for yet another /sys/proc entry.
> > 
> > Right now, I (for example) may have a use for Generic event handling, but 
for 
> > a program that needs XXX.XXX handles, and about XX.XXX events per second.
> > 
> > Right now, this program uses epoll, and reaches no limit at all, once you 
pass 
> > the "ulimit -n", and other kernel wide tunes of course, not related to 
epoll.
> > 
> > With your current kevent, I cannot switch to it, because of hardcoded 
limits.
> > 
> > I may be wrong, but what is currently missing for me is :
> > 
> > - No hardcoded limit on the max number of events. (A process that can open 
> > XXX.XXX files should be allowed to open a kevent queue with at least 
XXX.XXX 
> > events). Right now thats not clear what happens IF the current limit is 
> > reached.
> 
> This forces to overflows in fixed sized memory mapped buffer.
> If we remove memory mapped buffer or will allow to have overflows (and
> thus skipped entries) keven can easily scale to that limits (tested with
> xx.xxx events though).
> 
> > - In order to avoid touching the whole ring buffer, it might be good to be 
> > able to reset the indexes to the beginning when ring buffer is empty. (So 
if 
> > the user land is responsive enough to consume events, only first pages of 
the 
> > mapping would be used : that saves L1/L2 cpu caches)
> 
> And what happens when there are 3 empty at the beginning and \we need to
> put there 4 ready events?

Couldn't there be 3 areas in the mmap buffer:

- Unused: entries that the kernel can alloc from.
- Alloced: entries alloced by kernel but not yet used by user. Kernel can 
update these if new events requires that.
- Consumed: entries that the user are processing.

The user takes a set of alloced entries and make them consumed. Then it 
processes the events after which it makes them unused. 

If there are no unused entries and the kernel needs some, it has wait for free 
entries. The user has to notify when unused entries becomes available. It 
could set a flag in the mmap'ed area to avoid unnessesary wakeups.

The are some details with indexing and wakeup notification that I have left 
out, but I hope my idea is clear. I could give a more detailed description if 
requested. Also, I'm a user-level programmer so I might not get the whole 
picture.

Hans Henrik Happe

  parent reply	other threads:[~2006-10-05 14:01 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <115a6230591036@2ka.mipt.ru>
2006-09-12  8:41 ` [take18 0/4] kevent: Generic event handling mechanism Evgeniy Polyakov
2006-09-12  8:41   ` [take18 1/4] kevent: Core files Evgeniy Polyakov
2006-09-12  8:41     ` [take18 2/4] kevent: poll/select() notifications Evgeniy Polyakov
2006-09-12  8:41       ` [take18 3/4] kevent: Socket notifications Evgeniy Polyakov
2006-09-12  8:41         ` [take18 4/4] kevent: Timer notifications Evgeniy Polyakov
2006-09-20  9:35 ` [take19 0/4] kevent: Generic event handling mechanism Evgeniy Polyakov
2006-09-20  9:35   ` [take19 1/4] kevent: Core files Evgeniy Polyakov
2006-09-20  9:35     ` [take19 2/4] kevent: poll/select() notifications Evgeniy Polyakov
2006-09-20  9:35       ` [take19 3/4] kevent: Socket notifications Evgeniy Polyakov
2006-09-20  9:35         ` [take19 4/4] kevent: Timer notifications Evgeniy Polyakov
2006-10-04  6:34     ` [take19 1/4] kevent: Core files Ulrich Drepper
2006-10-04  6:48       ` Evgeniy Polyakov
2006-10-04 17:57         ` Ulrich Drepper
2006-10-05  8:57           ` Evgeniy Polyakov
2006-10-05  9:56             ` Eric Dumazet
2006-10-05 10:21               ` Evgeniy Polyakov
2006-10-05 10:45                 ` Eric Dumazet
2006-10-05 10:55                   ` Evgeniy Polyakov
2006-10-05 12:09                     ` Eric Dumazet
2006-10-05 12:37                       ` Evgeniy Polyakov
2006-10-15 23:22                         ` Ulrich Drepper
2006-10-16  7:33                           ` Evgeniy Polyakov
2006-10-16 10:16                             ` Ulrich Drepper
2006-10-16 11:23                               ` Evgeniy Polyakov
2006-10-17  5:10                           ` Johann Borck
2006-10-17  5:59                             ` Chase Venters
2006-10-17 10:42                               ` Evgeniy Polyakov
2006-10-17 13:12                                 ` Chase Venters
2006-10-17 13:35                                   ` Evgeniy Polyakov
2006-10-17 10:39                             ` Evgeniy Polyakov
2006-10-17 13:19                               ` Eric Dumazet
2006-10-17 13:42                                 ` Evgeniy Polyakov
2006-10-17 13:52                                   ` Eric Dumazet
2006-10-17 14:07                                     ` Evgeniy Polyakov
2006-10-17 14:25                                       ` Eric Dumazet
2006-10-17 15:09                                         ` Evgeniy Polyakov
2006-10-17 15:32                                           ` Eric Dumazet
2006-10-17 16:01                                             ` Evgeniy Polyakov
2006-10-17 16:26                                               ` Eric Dumazet
2006-10-17 16:35                                                 ` Evgeniy Polyakov
2006-10-17 16:45                                                   ` Eric Dumazet
2006-10-18  4:10                                                     ` Evgeniy Polyakov
2006-10-18  4:45                                                       ` Eric Dumazet
2006-10-17 15:33                                         ` Hans Henrik Happe
2006-10-05 14:01                 ` Hans Henrik Happe [this message]
2006-10-05 14:15                   ` Evgeniy Polyakov
2006-10-05 15:07                     ` Hans Henrik Happe
2006-09-22 19:22   ` [take19 0/4] kevent: Generic event handling mechanism Andrew Morton
2006-09-23  4:23     ` Evgeniy Polyakov
2006-10-04  6:09       ` Ulrich Drepper
2006-10-04  6:10         ` Ulrich Drepper
2006-10-04  6:27           ` Evgeniy Polyakov
2006-10-04  6:24         ` Evgeniy Polyakov
2006-09-26 15:54     ` Christoph Hellwig
2006-09-27  4:46       ` Evgeniy Polyakov
2006-09-27 15:09   ` Evgeniy Polyakov
2006-10-04  4:50     ` Ulrich Drepper
2006-10-04  4:55       ` Evgeniy Polyakov
2006-10-04  7:33         ` Ulrich Drepper
2006-10-04  7:48           ` Evgeniy Polyakov
2006-10-04 17:20             ` Ulrich Drepper
2006-10-05  9:02               ` Evgeniy Polyakov
2006-10-05 14:45                 ` Ulrich Drepper
2006-10-06  8:36                   ` Evgeniy Polyakov
2006-10-15 22:43                     ` Ulrich Drepper
2006-10-16  7:23                       ` Evgeniy Polyakov
2006-10-16  9:59                         ` Ulrich Drepper
2006-10-16 10:38                           ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610051601.20701.hhh@imada.sdu.dk \
    --to=hhh@imada.sdu.dk \
    --cc=akpm@osdl.org \
    --cc=chase.venters@clientec.com \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=drepper@gmail.com \
    --cc=drepper@redhat.com \
    --cc=hch@infradead.org \
    --cc=johann.borck@densedata.com \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=zach.brown@oracle.com \
    --subject='Re: [take19 1/4] kevent: Core files.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).