lkml.org 
[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHSET] mempool, percpu, blkcg: fix percpu stat allocation and remove stats_lock
On Thu, 8 Mar 2012 12:57:08 -0500
Vivek Goyal <vgoyal@redhat.com> 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 :(



\
 
 \ /
  Last update: 2012-03-08 20:09    [W:0.105 / U:2.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site