From: Stefani Seibold <stefani@seibold.net>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Amerigo Wang <xiyou.wangcong@gmail.com>,
Joe Perches <joe@perches.com>,
Roger Quadros <quadros.roger@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Shargorodsky Atal <ext-atal.shargorodsky@nokia.com>
Subject: Re: [PATCH 0/1] RFC: new kqueue API
Date: Mon, 14 Dec 2009 10:59:18 +0100 [thread overview]
Message-ID: <1260784758.19963.6.camel@wall-e> (raw)
In-Reply-To: <20091213183741.GB18989@one.firstfloor.org>
Am Sonntag, den 13.12.2009, 19:37 +0100 schrieb Andi Kleen:
> On Sun, Dec 13, 2009 at 11:37:13AM +0100, Stefani Seibold wrote:
> > As i figured out during the port the old kfifo API users, most of them
> > did not need a streamed fifo, because there work only with fixed size
> > entries. The kfifo is oversized for this kind of users, so i decided to
> > write a new kqueue API which is optimized for fixed size entries.
> >
> > There are a some benefits:
> >
> > - Performance (a put or get of an integer does only generate 4 assembly
> > instructions on a x86)
> > - Type save
> > - Cleaner interface
> > - Easier to use
> > - Less error prone
> > - Smaller footprint
> >
> > The API is similar to the new kfifo API, but there is no need for a
> > length paramter, because the size of the entry is know by the queue
> > structure.
>
> I must say I'm a bit sceptical if the advantages are really worth
> the additional code. That code would be always compiled in in addition
> to kfifo, so at least the code footprint would be always larger.
>
> Perhaps you could get the advantages for type-safety using
> inline wrappers to kfifo?
>
Okay, i found a nice solution to mix the new kqueue with my kfifo API.
- It its now type safe and the huger functions are now deinlined.
- Non dynamic allocated fifo did not need anymore the extra indirection
to the data buffer.
- And i moved the record stuff in an extra header and source file named
kfiforec.[ch].
Stefani
prev parent reply other threads:[~2009-12-14 9:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-13 10:37 [PATCH 0/1] RFC: new kqueue API Stefani Seibold
2009-12-13 10:39 ` [PATCH 1/1] " Stefani Seibold
2009-12-13 18:37 ` [PATCH 0/1] " Andi Kleen
2009-12-13 21:11 ` Stefani Seibold
2009-12-14 9:59 ` Stefani Seibold [this message]
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=1260784758.19963.6.camel@wall-e \
--to=stefani@seibold.net \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arnd@arndb.de \
--cc=ext-atal.shargorodsky@nokia.com \
--cc=gregkh@suse.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=quadros.roger@gmail.com \
--cc=xiyou.wangcong@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.