On Fri, Jun 10, 2016 at 12:06 AM, Jens Axboe wrote:
> On 05/30/2016 07:34 AM, Ming Lei wrote:
>>
>> Hi,
>>
>> Interests[1] have been shown in multipage bvecs, so this patchset
>> try to prepare for the support and do two things:
>>
>> 1) the 1st 4 patches use bvec iterator to
On Fri, Jun 10, 2016 at 12:06 AM, Jens Axboe wrote:
> On 05/30/2016 07:34 AM, Ming Lei wrote:
>>
>> Hi,
>>
>> Interests[1] have been shown in multipage bvecs, so this patchset
>> try to prepare for the support and do two things:
>>
>> 1) the 1st 4 patches use bvec iterator to implement
On 05/30/2016 07:34 AM, Ming Lei wrote:
Hi,
Interests[1] have been shown in multipage bvecs, so this patchset
try to prepare for the support and do two things:
1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
then we can drop the non-standard way for iterating bvec, which
On 05/30/2016 07:34 AM, Ming Lei wrote:
Hi,
Interests[1] have been shown in multipage bvecs, so this patchset
try to prepare for the support and do two things:
1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
then we can drop the non-standard way for iterating bvec, which
On Wed, Jun 1, 2016 at 9:51 PM, Mike Snitzer wrote:
> On Wed, Jun 01 2016 at 9:44am -0400,
> Christoph Hellwig wrote:
>
>> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
>> > > be dm-crypt.c. Maybe you've identified some indirect use of
>> > >
On Wed, Jun 1, 2016 at 9:51 PM, Mike Snitzer wrote:
> On Wed, Jun 01 2016 at 9:44am -0400,
> Christoph Hellwig wrote:
>
>> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
>> > > be dm-crypt.c. Maybe you've identified some indirect use of
>> > > BIO_MAX_SIZE?
>> >
>> > I mean the
On Wed, Jun 01, 2016 at 09:51:51AM -0400, Mike Snitzer wrote:
> So should I not push this type of fix to Linus now? I was going to send
> the above commit and this one to him this week:
>
On Wed, Jun 01, 2016 at 09:51:51AM -0400, Mike Snitzer wrote:
> So should I not push this type of fix to Linus now? I was going to send
> the above commit and this one to him this week:
>
On Wed, Jun 01 2016 at 9:53am -0400,
Hannes Reinecke wrote:
> On 06/01/2016 03:43 PM, Christoph Hellwig wrote:
> > These patches look good on their own. They might be an easier sell
> > just as bio cleanups :)
>
> Fully agree. I've seen (some) improvements with those patches, so
On Wed, Jun 01 2016 at 9:53am -0400,
Hannes Reinecke wrote:
> On 06/01/2016 03:43 PM, Christoph Hellwig wrote:
> > These patches look good on their own. They might be an easier sell
> > just as bio cleanups :)
>
> Fully agree. I've seen (some) improvements with those patches, so
> I'd prefer
On 06/01/2016 03:43 PM, Christoph Hellwig wrote:
> These patches look good on their own. They might be an easier sell
> just as bio cleanups :)
Fully agree. I've seen (some) improvements with those patches, so
I'd prefer to have them.
You can add:
Tested-by: Hannes Reinecke
On 06/01/2016 03:43 PM, Christoph Hellwig wrote:
> These patches look good on their own. They might be an easier sell
> just as bio cleanups :)
Fully agree. I've seen (some) improvements with those patches, so
I'd prefer to have them.
You can add:
Tested-by: Hannes Reinecke
Cheers,
Hannes
On Wed, Jun 01 2016 at 9:44am -0400,
Christoph Hellwig wrote:
> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > > be dm-crypt.c. Maybe you've identified some indirect use of
> > > BIO_MAX_SIZE?
> >
> > I mean the recently introduced BIO_MAX_SIZE in -next
On Wed, Jun 01 2016 at 9:44am -0400,
Christoph Hellwig wrote:
> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > > be dm-crypt.c. Maybe you've identified some indirect use of
> > > BIO_MAX_SIZE?
> >
> > I mean the recently introduced BIO_MAX_SIZE in -next tree:
> >
> >
On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > be dm-crypt.c. Maybe you've identified some indirect use of
> > BIO_MAX_SIZE?
>
> I mean the recently introduced BIO_MAX_SIZE in -next tree:
>
>
On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > be dm-crypt.c. Maybe you've identified some indirect use of
> > BIO_MAX_SIZE?
>
> I mean the recently introduced BIO_MAX_SIZE in -next tree:
>
>
These patches look good on their own. They might be an easier sell
just as bio cleanups :)
These patches look good on their own. They might be an easier sell
just as bio cleanups :)
On Tue, May 31, 2016 at 11:53 PM, Mike Snitzer wrote:
> On Mon, May 30 2016 at 9:34am -0400,
> Ming Lei wrote:
>
>>
>> Hi,
>>
>> Interests[1] have been shown in multipage bvecs, so this patchset
>> try to prepare for the support and do two things:
>>
On Tue, May 31, 2016 at 11:53 PM, Mike Snitzer wrote:
> On Mon, May 30 2016 at 9:34am -0400,
> Ming Lei wrote:
>
>>
>> Hi,
>>
>> Interests[1] have been shown in multipage bvecs, so this patchset
>> try to prepare for the support and do two things:
>>
>> 1) the 1st 4 patches use bvec iterator to
On Mon, May 30 2016 at 9:34am -0400,
Ming Lei wrote:
>
> Hi,
>
> Interests[1] have been shown in multipage bvecs, so this patchset
> try to prepare for the support and do two things:
>
> 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
> then we can
On Mon, May 30 2016 at 9:34am -0400,
Ming Lei wrote:
>
> Hi,
>
> Interests[1] have been shown in multipage bvecs, so this patchset
> try to prepare for the support and do two things:
>
> 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
> then we can drop the non-standard
Hi,
Interests[1] have been shown in multipage bvecs, so this patchset
try to prepare for the support and do two things:
1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
then we can drop the non-standard way for iterating bvec, which
can be thought as a good cleanup for
Hi,
Interests[1] have been shown in multipage bvecs, so this patchset
try to prepare for the support and do two things:
1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
then we can drop the non-standard way for iterating bvec, which
can be thought as a good cleanup for
24 matches
Mail list logo