[lkml]   [2011]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHSET] block, mempool, percpu: implement percpu mempool and fix blkcg percpu alloc deadlock

On Thu, Dec 22, 2011 at 03:41:38PM -0800, Andrew Morton wrote:
> All the code I'm looking at assumes that blkio_group.stats_cpu is
> non-zero. Won't the kerenl just go splat if that allocation failed?
> If the code *does* correctly handle ->stats_cpu == NULL then we have
> options.

I think it's supposed to just skip creating whole blk_group if percpu
allocation fails, so ->stats_cpu of existing groups are guaranteed to
be !%NULL.

> a) Give userspace a new procfs/debugfs file to start stats gathering
> on a particular cgroup/request_queue pair. Allocate the stats
> memory in that.
> b) Or allocate stats_cpu on the first call to blkio_read_stat_cpu()
> and return zeroes for this first call.

Hmmm... IIRC, the stats aren't exported per cgroup-request_queue pair,
so reads are issued per cgroup. We can't tell which request_queues
userland is actually interested in.

> c) Or change the low-level code to do
> blkio_group.want_stats_cpu=true, then test that at the top level
> after we've determined that blkio_group.stats_cpu is NULL.

Not following. Where's the "top level"?

> d) Or, worse, punt the allocation into a workqueue thread.

I would much prefer using mempool to this. They are essentially the
same approach.



 \ /
  Last update: 2011-12-23 00:57    [W:0.077 / U:1.212 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site