On Tue, Apr 09, 2013 at 05:18:25PM -0400, Mikulas Patocka wrote:
[..]
> > bio_associate_current() return -EBUSY if bio has already been associated
> > with an io context.
> >
> > So in a stack if every driver calls bio_associate_current(), upon bio
> > submission, it will automatically amke sure
On Tue, 9 Apr 2013, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 04:32:28PM -0400, Mikulas Patocka wrote:
>
> [..]
> > Generally, we shouldn't associate bios with "current" task in device
> > mapper targets. For example suppose that we have two stacked dm-crypt
> > targets:
> >
> > In the "cu
On Tue, Apr 09, 2013 at 04:32:28PM -0400, Mikulas Patocka wrote:
[..]
> Generally, we shouldn't associate bios with "current" task in device
> mapper targets. For example suppose that we have two stacked dm-crypt
> targets:
>
> In the "current" process pointer in lower dm-crypt target's request
On Tue, Apr 09, 2013 at 02:02:01PM -0700, Tejun Heo wrote:
> For testing, copying bi_ioc and bi_css directly is fine but please add
> another interface to copy those for the actual code. Say,
> bio_copy_association(@to_bio, @from_bio) or whatever.
Another and probably better possibility is just r
Hey,
On Tue, Apr 09, 2013 at 04:32:28PM -0400, Mikulas Patocka wrote:
> > and we probably need to change that to bio_associate_task().
>
> Generally, we shouldn't associate bios with "current" task in device
> mapper targets. For example suppose that we have two stacked dm-crypt
> targets:
It
On Tue, 9 Apr 2013, Tejun Heo wrote:
> On Tue, Apr 09, 2013 at 03:42:16PM -0400, Mikulas Patocka wrote:
> > If I drop ifdefs, it doesn't compile (because other cgroup stuff it
> > missing).
> >
> > So I enabled bio cgroups.
> >
> > bio_associate_current can't be used, because by the time we a
On Tue, Apr 09, 2013 at 03:42:16PM -0400, Mikulas Patocka wrote:
> If I drop ifdefs, it doesn't compile (because other cgroup stuff it
> missing).
>
> So I enabled bio cgroups.
>
> bio_associate_current can't be used, because by the time we allocate the
> outgoing write bio, we are no longer in
On Tue, 9 Apr 2013, Tejun Heo wrote:
> Hey,
>
> On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > > Hmmm? Why not just keep the issuing order along with plugging
> > > boundaries?
> >
> > What do you mean?
> >
> > I used to have a patch that keeps order of requests as they
On Tue, Apr 09, 2013 at 11:57:21AM -0700, Tejun Heo wrote:
[..]
> And destroy all per-ioc and cgroup logics in block layer in the
> process.
Oh, I am in no-way suggesting don't use bio_associate_current(). I am
just trying to analyze the performance issue right now and saying that
as far as perf
Hello,
On Tue, Apr 09, 2013 at 02:42:48PM -0400, Vivek Goyal wrote:
> I guess plugging boundary is more important than issuing order as
> block layer should take care of mering the bio and put in right
> order (attempt_plug_merge()).
Yeah, the exact order probably doesn't affect things too much
On Tue, Apr 09, 2013 at 11:10:31AM -0700, Tejun Heo wrote:
> Hey,
>
> On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > > Hmmm? Why not just keep the issuing order along with plugging
> > > boundaries?
> >
> > What do you mean?
> >
> > I used to have a patch that keeps order o
On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> Hi
>
> I placed the dm-crypt parallization patches at:
> http://people.redhat.com/~mpatocka/patches/kernel/dm-crypt-paralelizace/current/
>
> The patches paralellize dm-crypt and make it possible to use all processor
> cores.
>
Hey,
On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > Hmmm? Why not just keep the issuing order along with plugging
> > boundaries?
>
> What do you mean?
>
> I used to have a patch that keeps order of requests as they were
> introduced, but sorting the requests according to
On Tue, 9 Apr 2013, Tejun Heo wrote:
> On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> > The patch dm-crypt-sort-requests.patch sorts write requests submitted by a
> > single thread. The requests are sorted according to the sector number,
> > rb-tree is used for efficient so
On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> The patch dm-crypt-sort-requests.patch sorts write requests submitted by a
> single thread. The requests are sorted according to the sector number,
> rb-tree is used for efficient sorting.
Hmmm? Why not just keep the issuing orde
15 matches
Mail list logo
