Hey,
On Wed, May 22, 2013 at 02:50:14PM -0400, Mike Snitzer wrote:
> Was wondering: how is percpu-refcounting coming along? Do you have a
> pointer to the code that can be pulled in for use by Mikulas' dm-crypt
> changes?
>
> Would be nice to get this stuff sorted out for the 3.11 merge window.
On Thu, Apr 18 2013 at 1:03pm -0400,
Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, Apr 18, 2013 at 12:47:42PM -0400, Mike Snitzer wrote:
> > I see you nack and raise you with: please reconsider in the near term.
>
> The thing is that percpu-refcnting is already in mostly ready-form, so
> unless
On Thu, Apr 18 2013 at 1:03pm -0400,
Tejun Heo t...@kernel.org wrote:
Hello, Mike.
On Thu, Apr 18, 2013 at 12:47:42PM -0400, Mike Snitzer wrote:
I see you nack and raise you with: please reconsider in the near term.
The thing is that percpu-refcnting is already in mostly ready-form, so
Hey,
On Wed, May 22, 2013 at 02:50:14PM -0400, Mike Snitzer wrote:
Was wondering: how is percpu-refcounting coming along? Do you have a
pointer to the code that can be pulled in for use by Mikulas' dm-crypt
changes?
Would be nice to get this stuff sorted out for the 3.11 merge window.
Hello, Mike.
On Thu, Apr 18, 2013 at 12:47:42PM -0400, Mike Snitzer wrote:
> I see you nack and raise you with: please reconsider in the near term.
The thing is that percpu-refcnting is already in mostly ready-form, so
unless this dm series is planned to be merged for v3.10-rc1, I don't
see the
On Tue, Apr 16 2013 at 1:24pm -0400,
Tejun Heo wrote:
> Hey,
>
> On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
> > 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
> >
On Tue, Apr 16 2013 at 1:24pm -0400,
Tejun Heo t...@kernel.org wrote:
Hey,
On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
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
Hello, Mike.
On Thu, Apr 18, 2013 at 12:47:42PM -0400, Mike Snitzer wrote:
I see you nack and raise you with: please reconsider in the near term.
The thing is that percpu-refcnting is already in mostly ready-form, so
unless this dm series is planned to be merged for v3.10-rc1, I don't
see the
On Tue, 16 Apr 2013, Tejun Heo wrote:
> Hey,
>
> On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
> > 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
Hey,
On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
> 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.
The whole world isn't
Hey,
On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
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.
The whole world isn't
On Tue, 16 Apr 2013, Tejun Heo wrote:
Hey,
On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
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
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
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
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
>
On Thu, 11 Apr 2013, Tejun Heo wrote:
> On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
> > All that I can tell you is that adding an empty atomic operation
> > "cmpxchg(>bi_css->refcnt, bio->bi_css->refcnt, bio->bi_css->refcnt);"
> > to bio_clone_context and
On Thu, 11 Apr 2013, Tejun Heo wrote:
> On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
> > If this becomes an actual bottleneck, the right thing to do is making
> > css ref per-cpu. Please stop messing around with refcounting.
>
> If you think this kind of hackery is acceptable,
On Thu, 11 Apr 2013, Tejun Heo wrote:
On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
If this becomes an actual bottleneck, the right thing to do is making
css ref per-cpu. Please stop messing around with refcounting.
If you think this kind of hackery is acceptable, you
On Thu, 11 Apr 2013, Tejun Heo wrote:
On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
All that I can tell you is that adding an empty atomic operation
cmpxchg(bio-bi_css-refcnt, bio-bi_css-refcnt, bio-bi_css-refcnt);
to bio_clone_context and bio_disassociate_task
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
On 12.4.2013 2:22, Tejun Heo wrote:
> On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
>> All that I can tell you is that adding an empty atomic operation
>> "cmpxchg(>bi_css->refcnt, bio->bi_css->refcnt, bio->bi_css->refcnt);"
>> to bio_clone_context and bio_disassociate_task
On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
> All that I can tell you is that adding an empty atomic operation
> "cmpxchg(>bi_css->refcnt, bio->bi_css->refcnt, bio->bi_css->refcnt);"
> to bio_clone_context and bio_disassociate_task increases the time to run a
> benchmark
On Thu, 11 Apr 2013, Tejun Heo wrote:
> On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
> > If this becomes an actual bottleneck, the right thing to do is making
> > css ref per-cpu. Please stop messing around with refcounting.
>
> If you think this kind of hackery is acceptable,
On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
> If this becomes an actual bottleneck, the right thing to do is making
> css ref per-cpu. Please stop messing around with refcounting.
If you think this kind of hackery is acceptable, you really need to
re-evaluate your priorities in
On Thu, Apr 11, 2013 at 03:49:20PM -0400, Mikulas Patocka wrote:
> If the bi_css pointer points to a structure that is shared between
> processes, using atomic instruction causes cache line boucing - it doesn't
> cost a few instructions, it costs 2-3 hundreds cycles.
>
> I modified the patch to
On Wed, 10 Apr 2013, Tejun Heo wrote:
> On Wed, Apr 10, 2013 at 07:42:59PM -0400, Mikulas Patocka wrote:
> > /*
> > + * bio_clone_context copies cgroup context from the original bio to the
> > new bio.
> > + * It is used by bio midlayer drivers that create new bio based on an
> > original
>
On Wed, 10 Apr 2013, Tejun Heo wrote:
On Wed, Apr 10, 2013 at 07:42:59PM -0400, Mikulas Patocka wrote:
/*
+ * bio_clone_context copies cgroup context from the original bio to the
new bio.
+ * It is used by bio midlayer drivers that create new bio based on an
original
+ * bio and
On Thu, Apr 11, 2013 at 03:49:20PM -0400, Mikulas Patocka wrote:
If the bi_css pointer points to a structure that is shared between
processes, using atomic instruction causes cache line boucing - it doesn't
cost a few instructions, it costs 2-3 hundreds cycles.
I modified the patch to use
On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
If this becomes an actual bottleneck, the right thing to do is making
css ref per-cpu. Please stop messing around with refcounting.
If you think this kind of hackery is acceptable, you really need to
re-evaluate your priorities in
On Thu, 11 Apr 2013, Tejun Heo wrote:
On Thu, Apr 11, 2013 at 12:52:03PM -0700, Tejun Heo wrote:
If this becomes an actual bottleneck, the right thing to do is making
css ref per-cpu. Please stop messing around with refcounting.
If you think this kind of hackery is acceptable, you
On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
All that I can tell you is that adding an empty atomic operation
cmpxchg(bio-bi_css-refcnt, bio-bi_css-refcnt, bio-bi_css-refcnt);
to bio_clone_context and bio_disassociate_task increases the time to run a
benchmark from 23 to
On 12.4.2013 2:22, Tejun Heo wrote:
On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
All that I can tell you is that adding an empty atomic operation
cmpxchg(bio-bi_css-refcnt, bio-bi_css-refcnt, bio-bi_css-refcnt);
to bio_clone_context and bio_disassociate_task increases the
32 matches
Mail list logo
