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
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 n
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
> > intro
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 pos
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 compo
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 count
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
> po
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_disassoc
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, yo
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_tas
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
> benchmar
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, yo
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 mak
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
> >
16 matches
Mail list logo
