Re: [PATCHSET] mempool, percpu, blkcg: fix percpu stat allocationand remove stats_lock

From: Andrew Morton
Date: Thu Mar 08 2012 - 14:06:19 EST


On Thu, 8 Mar 2012 12:57:08 -0500
Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:

> On Wed, Mar 07, 2012 at 03:05:49PM -0800, Andrew Morton wrote:
>
> [..]
> > > > btw, speaking of uniprocessor: please do perform a uniprocessor build
> > > > and see what impact the patch has upon the size(1) output for the .o
> > > > files. We should try to minimize the pointless bloat for the UP
> > > > kernel.
> > >
> > > But this logic is required both for UP and SMP kernels. So bloat on UP
> > > is not unnecessary?
> >
> > UP doesn't need a per-cpu variable, hence it doesn't need to run
> > alloc_per_cpu() at all. For UP all we need to do is to aggregate a
> > `struct blkio_group_stats' within `struct blkg_policy_data'?
> >
> > This could still be done with suitable abstraction and wrappers.
> > Whether that's desirable depends on how fat the API ends up, I guess.
> >
>
> Ok, here is the patch which gets rid of allocating per cpu stats in case
> of UP. Here are the size stats with and without patch.
>
> Without patch (UP kernel)
> -------------------------
> # size block/blk-cgroup.o
> text data bss dec hex filename
> 13377 5504 58 18939 49fb block/blk-cgroup.o
>
> With patch (UP kernel)
> ----------------------
> # size block/blk-cgroup.o
> text data bss dec hex filename
> 12678 5312 49 18039 4677 block/blk-cgroup.o
>
> Do you think it is worth introducing these ifdefs.

That's a fairly nice improvement and the ifdeffery isn't excessive.

I'd be concerned about having two such different code paths though: it
weakens our performance testing coverage and I expect that most core
kernel developers only test SMP.

Perhaps a better approach would be to make the percpu stuff separately
configurable, so that SMP people can test it and so that small SMP can
avoid it as well. (Do we know that the percpu feature is a net win on
a 2-way?).

It's quite common for us to degrade UP in favor of SMP, often in the
area of percpuification. This is bad. But blkcg surely isn't the most
appropriate place to start addressing this :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/