On Wed, Dec 14, 2011 at 10:16:23AM -0800, Tejun Heo wrote: [..] > > > > Or may be there is a safer version of pcpu alloc which will return > > > > without allocation if pcpu_alloc_mutex is already locked. > > pcpu alloc depends on vmalloc allocation, so it isn't trivial. We can > try to make percpu keep cache of areas for this type of allocation but > I personally think doing percpu allocation from atomic context or IO > path is a bad idea. Hmmm... Looks like I am running out of options here. I can't find a suitable path where I can allocate these stats out of IO path. Because devices can be plugged in dynamically (and these stats are per cgroup, per device), and cgroups can be created dynamically after device creation, I can't do any static allocation out of IO path. So that kind of makes use of per cpu memory areas for stats in this case impossible. For a moment I thought of doing allocation from worker thread after taking a reference on the original group. Allow the IO submission to continue without blocking. Just that till per cpu areas are allocated, we will not collect any stats. But for locking we rely on request queue lock and request queue might be gone by the time per cpu areas are allocated. That means we need a group refenrence on the request queue. Request queue referencing and life time is already full of bugs. So I don't feel comfortable adding more code there (till atleast your cleanup patches go in). Hmm..., is revert of per cpu blkio group stats the only sane choice left now. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
