[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1317666154.16137.727.camel@nimitz>
Date: Mon, 03 Oct 2011 11:22:34 -0700
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: Nitin Gupta <ngupta@...are.org>
Cc: Dan Magenheimer <dan.magenheimer@...cle.com>,
Seth Jennings <sjenning@...ux.vnet.ibm.com>,
Greg KH <greg@...ah.com>, gregkh@...e.de,
devel@...verdev.osuosl.org, cascardo@...oscopio.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
brking@...ux.vnet.ibm.com, rcj@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support
On Mon, 2011-10-03 at 13:54 -0400, Nitin Gupta wrote:
> I think disabling preemption on the local CPU is the cheapest we can get
> to protect PCPU buffers. We may experiment with, say, multiple buffers
> per CPU, so we end up disabling preemption only in highly improbable
> case of getting preempted just too many times exactly within critical
> section.
I guess the problem is two-fold: preempt_disable() and
local_irq_save().
> static int zcache_put_page(int cli_id, int pool_id, struct tmem_oid *oidp,
> uint32_t index, struct page *page)
> {
> struct tmem_pool *pool;
> int ret = -1;
>
> BUG_ON(!irqs_disabled());
That tells me "zcache" doesn't work with interrupts on. It seems like
awfully high-level code to have interrupts disabled. The core page
allocator has some irq-disabling spinlock calls, but that's only really
because it has to be able to service page allocations from interrupts.
What's the high-level reason for zcache?
I'll save the discussion about preempt for when Seth posts his patch.
-- Dave
--
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