From: Stelian Pop <stelian@popies.net>
To: Andrea Arcangeli <andrea@novell.com>
Cc: Hugh Dickins <hugh@veritas.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC, 2.6] a simple FIFO implementation
Date: Fri, 17 Sep 2004 15:36:58 +0200 [thread overview]
Message-ID: <20040917133656.GF3089@crusoe.alcove-fr> (raw)
In-Reply-To: <20040917131523.GQ15426@dualathlon.random>
On Fri, Sep 17, 2004 at 03:15:23PM +0200, Andrea Arcangeli wrote:
> this is nice, I had to write a ring buffer myself last month for
> bootcache (you can find the patch on l-k searching for "bootcache"). It
> was fun so I don't mind but certainly it took me a few reboots to make
> it work ;)
Making the code separate helps also for testing it in usermode (minus
the lock), so I haven't had to reboot (yet) :)
> My main issue with this is that I don't like to use kmalloc, I expect
> most people will use a page anyways, I'm using alloc_page myself (and I
> may want to switch to vmalloc to get a larger buffer, that's fine for
> bootcache since the allocation is in a slow path). I wonder if it worth
> to generalize the allocator passing down a callback or something like
> that. I can still use kmalloc but it'd be just a waste of some memory
> and risk fragmentation for >PAGE_SIZE (OTOH the callback as well will
> waste some byte).
What about leaving kfifo_alloc as is (using kmalloc) and adding
struct kfifo *kfifo_init(unsigned char *buffer, spinlock_t *lock);
which let's you specify the buffer and the spinlock you want to use.
Of course, one should not call kfifo_free() on such a struct kfifo...
As a special case, the spinlock can be NULL and in this case it
allocates it. But in this case we should also make a kfifo_delete()
to deallocate the lock...
> The other issue with the locking is that I will not need locking since
> I've my own external locking used for other stuff too that serializes
> the fifo as well, so I wonder if the "spinlock_t *" could as well be
> passed down to kfifo_get so I won't need to allocate the spinlock
> structure as well inside the kfifo. Otherwise I could start to use such
> a spinlock inside the kfifo for the external locking too (and then I
> could call only the __ functions), that means guys outside your
> kfifo.[ch] would use the kfifo->lock which doesn't sound that clean,
> kfifo using an external lock passed down by the caller as parameter
> looks more robust.
See above for the lock.
It is better to use an external lock if you want to use it for more
that just protecting the fifo. Unfortunately we cannot hide the
internal spinlock from the users, this is just C.
Stelian.
--
Stelian Pop <stelian@popies.net>
next prev parent reply other threads:[~2004-09-17 13:37 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 13:52 Stelian Pop
2004-09-15 10:20 ` Stelian Pop
2004-09-15 11:10 ` Tonnerre
2004-09-15 11:25 ` Alan Cox
2004-09-15 13:27 ` Dmitry Torokhov
2004-09-15 14:21 ` Stelian Pop
2004-09-15 22:30 ` Andrew Morton
2004-09-16 6:43 ` Stelian Pop
2004-09-16 7:04 ` Andrew Morton
2004-09-16 10:45 ` Stelian Pop
2004-09-16 13:57 ` Paul Jackson
2004-09-16 14:09 ` Stelian Pop
2004-09-16 15:45 ` Paul Jackson
2004-09-16 15:59 ` Stelian Pop
2004-09-16 15:09 ` Buddy Lucas
2004-09-16 15:29 ` Stelian Pop
2004-09-16 15:51 ` Buddy Lucas
2004-09-16 15:52 ` Stelian Pop
2004-09-16 16:07 ` Buddy Lucas
2004-09-16 18:30 ` Stelian Pop
2004-09-16 22:52 ` Buddy Lucas
2004-09-16 17:00 ` Andrew Morton
2004-09-16 18:09 ` Stelian Pop
2004-09-17 0:18 ` Andrew Morton
2004-09-17 10:24 ` Stelian Pop
2004-09-17 11:28 ` Paul Jackson
2004-09-17 11:44 ` Hugh Dickins
2004-09-17 12:24 ` Stelian Pop
2004-09-17 12:37 ` Duncan Sands
2004-09-17 12:48 ` Stelian Pop
2004-09-17 13:00 ` Duncan Sands
2004-09-17 13:05 ` Stelian Pop
2004-09-17 13:16 ` Duncan Sands
2004-09-17 13:15 ` Andrea Arcangeli
2004-09-17 13:36 ` Stelian Pop [this message]
2004-09-17 13:41 ` Andrea Arcangeli
2004-09-17 14:00 ` Stelian Pop
2004-09-17 15:14 ` Andrea Arcangeli
2004-09-17 14:47 ` Paul Jackson
2004-09-17 12:52 ` James R Bruce
2004-09-17 15:48 ` Stelian Pop
2004-09-17 16:01 ` Andrea Arcangeli
2004-09-17 16:14 ` Hugh Dickins
2004-09-17 20:50 ` Stelian Pop
2004-09-17 21:28 ` Andrea Arcangeli
2004-09-17 21:54 ` Ryan Cumming
2004-09-17 22:00 ` Andrea Arcangeli
2004-09-17 22:14 ` Ryan Cumming
2004-09-17 22:35 ` Andrew Morton
2004-09-18 0:07 ` Ryan Cumming
2004-09-17 22:29 ` Ryan Cumming
2004-09-18 3:41 ` Kyle Moffett
2004-09-18 7:56 ` Ryan Cumming
2004-09-17 22:07 ` Andrew Morton
2004-09-20 15:14 ` Stelian Pop
2004-09-20 18:01 ` Sasha Khapyorsky
2004-09-20 18:22 ` Stelian Pop
2004-09-20 19:00 ` Richard B. Johnson
2004-09-16 15:57 ` Bill Davidsen
2004-09-17 10:25 ` Stelian Pop
[not found] <260353727@toto.iv>
2004-09-17 1:00 ` Peter Chubb
2004-09-17 5:45 ` Chris Friesen
2004-09-17 11:58 ` Anton Blanchard
2004-09-17 10:32 ` Stelian Pop
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=20040917133656.GF3089@crusoe.alcove-fr \
--to=stelian@popies.net \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®