[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87skg8u51n.fsf@basil.nowhere.org>
Date: Mon, 03 Aug 2009 20:27:00 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Stefani Seibold <stefani@...bold.net>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC 0/2] new kfifo API
Stefani Seibold <stefani@...bold.net> writes:
> the buffer. No extra indirection is needed to access the fifo buffer.
> - Lockless access: if only one reader and one writer is active on the fifo,
> which is the common use case, there is no additional locking necessary.
Would it also be NMI safe? I've been looking at a new log buffer
for MCE/NMI. One option was the fifo in ftrace, but it seems
so big that it would blow up the machine check code considerably.
There was also an own new fifo that Ying Huang implemented,
but that one wasn't very popular.
This might be indeed an alternative. Requirement is NMI-safeness.
> The API:
> --------
>
> struct kfifo *kfifo_alloc(unsigned long size, gfp_t gfp_mask)
> Dynamically allocates a new fifo and returns the address
> @size: the size of the internal buffer to be allocated.
> @gfp_mask: get_free_pages mask, passed to kmalloc()
For the MCE use case this would need to be able to optionally use
bootmem because the first initialization happens too early.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists