Re: [PATCH v2] make dm and dm-crypt forward cgroup context (was:dm-crypt parallelization patches)

[Mikulas Patocka]

On Fri, 12 Apr 2013, Tejun Heo wrote:

> On Fri, Apr 12, 2013 at 02:01:08PM -0400, Mikulas Patocka wrote:
> > So if you think that reference counts should be incremented by every clone 
> > of the original bio, what kind of bug should it protect against? If we 
> > don't increment reference counts for pages, why should we do it for cgroup 
> > pointers?
> 
> These things are called trade-offs.  You look at the overhead of the
> things and how complex / fragile things get when certain shortcuts are
> taken and how well contained and easy to verify / debug when things go
> wrong and then make your choice.

So what we are here trading for what?


The patch eliminates the atomic references when passing the bio down the 
stack of bio drivers.


The patch adds a flag BIO_DROP_CGROUP_REFCOUNT, modifies it at two places 
and tests it on two places - that is not big.

The flag BIO_DROP_CGROUP_REFCOUNT is never supposed to be used outside bio 
cgroup functions, so it doesn't complicate interface to other subsystems.

The patch is not bug-prone, because we already must make sure that the 
cloned bio has shorter lifetime than the master bio - so the patch doesn't 
introduce any new possibilities to make bugs.


> Do the two really look the same to you?  The page refs are much more
> expensive, mostly contained in and the main focus of dm.  ioc/css refs
> aren't that expensive to begin with, css refcnting is widely scattered

ioc is per-task, so it is likely to be cached (but there are processors 
that have slow atomic operations even on cached data - on Pentium 4 it 
takes about 100 cycles). But css is shared between tasks and produces the 
cache ping-pong effect.

> across the kernel, the association interface is likely to be used by
> any entity issuing IOs asynchronously soonish, and there is much saner
> way to improve it - which would be beneficial not only to block / dm
> but everyone else using it.
> 
> Something being done in one place doesn't automatically make it okay
> everywhere else.  We can and do use hackery but *with* discretion.
>
> If you still can't understand, I'm not sure what more I can tell you.
> 
> -- 
> tejun

I don't know what's wrong with 4 lines of code to manipulate a flag.

I understand that you don't want to do something complicated and bug-prone 
to improve performance. But the patch is neither complicated nor 
bug-prone.

Mikulas
--
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/