lkml.org 
[lkml]   [2011]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET] block, mempool, percpu: implement percpu mempool and fix blkcg percpu alloc deadlock
    On Tue, 27 Dec 2011 09:52:49 -0800
    Tejun Heo <tj@kernel.org> wrote:

    > Hello, KAMEZAWA.
    >
    > On Mon, Dec 26, 2011 at 03:05:31PM +0900, KAMEZAWA Hiroyuki wrote:
    > > From 433b56fd5644d4b1e695bc16bbf8dd78842999fd Mon Sep 17 00:00:00 2001
    > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    > > Date: Mon, 26 Dec 2011 15:06:21 +0900
    > > Subject: [PATCH] percpu_counter: add lazy init
    > >
    > > percpu_counter calls alloc_percpu(). This means percpu_counter_init()
    > > assumes GFP_KERNEL context. This may call vmalloc() in percpu_counter
    > > allocation and will have locks.
    > >
    > > If a caller doesn't want to assume GFP_KERNEL, we need some tricks.
    > > This patch adds percpu_counter_init_lazy().
    > >
    > > At lazy allocation, the function leaves fbc->counters as NULL and
    > > init fbc->counters by workqueue. This work item handling is done
    > > by fbc->list, so, the struct size of 'fbc' will not increase if
    > > a user configs CONFIG_HOTPLUG_CPU.
    >
    > This is essentially more specialized form of the mempool approach. It
    > doesn't seem any simpler to me while being less generic. I don't see
    > what the upside would be.
    >

    Hm, but this never causes -ENOMEM error, at all.

    Thanks,
    -Kame



    \
     
     \ /
      Last update: 2011-12-28 01:17    [W:0.025 / U:0.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site