All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Javier González" <jg@lightnvm.io>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	"Matias Bjørling" <mb@lightnvm.io>, "Jens Axboe" <axboe@fb.com>,
	linux-block@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Matias Bjørling" <matias@cnexlabs.com>
Subject: Re: [PATCH 10/18] lightnvm: pblk: use bio_copy_kern when possible
Date: Thu, 7 Sep 2017 04:08:01 -0700	[thread overview]
Message-ID: <20170907110801.GA17144@infradead.org> (raw)
In-Reply-To: <EE4FE7F3-88CF-42DD-B18F-B0AC2CB5EB2C@lightnvm.io>

On Wed, Sep 06, 2017 at 04:00:56PM +0200, Javier Gonz�lez wrote:
> > Nope.  You want to loop over vmalloc_to_page and call bio_add_page
> > for each page,
> 
> Yes. This is basically what I did before.
> 
> > after taking care of virtually tagged caches instead
> > of this bounce buffering.
> 
> And thus I considered bio_copy_kern to be a better solution, since it
> will through time take care of doing the vmalloc_to_page correctly for
> all cases.

bio_copy_kern copies all the data, so it is generally not a good
idea.  The cache flushing isn't too hard - take a look at the XFS
buffer cache for an existing version.

It would be good to just to do the right thing inside bio_map_kern
for that so that callers don't need to care if it is vmalloced or
not.

> Ok. So this would mean that targets (e.g., pblk) deal with struct
> request instead of only dealing with bios and then letting the LightNVM
> core transforming bios to requests. This way we can directly map to the
> request. Is this what you mean?

Yes.

> Just out of curiosity, why is forming the bio trough bio_copy_kern (or
> manually doing the same) and then transforming to a request incorrect /
> worse?

Because you expose yourself to the details of mapping a bio to request.
We had to export blk_init_request_from_bio just for lightnvm to do this,
and it also has to do weird other bits about requests.  If you go
through blk_rq_map_* the block layer takes care of all that for you.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: "Javier González" <jg@lightnvm.io>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	"Matias Bjørling" <mb@lightnvm.io>, "Jens Axboe" <axboe@fb.com>,
	linux-block@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Matias Bjørling" <matias@cnexlabs.com>
Subject: Re: [PATCH 10/18] lightnvm: pblk: use bio_copy_kern when possible
Date: Thu, 7 Sep 2017 04:08:01 -0700	[thread overview]
Message-ID: <20170907110801.GA17144@infradead.org> (raw)
In-Reply-To: <EE4FE7F3-88CF-42DD-B18F-B0AC2CB5EB2C@lightnvm.io>

On Wed, Sep 06, 2017 at 04:00:56PM +0200, Javier González wrote:
> > Nope.  You want to loop over vmalloc_to_page and call bio_add_page
> > for each page,
> 
> Yes. This is basically what I did before.
> 
> > after taking care of virtually tagged caches instead
> > of this bounce buffering.
> 
> And thus I considered bio_copy_kern to be a better solution, since it
> will through time take care of doing the vmalloc_to_page correctly for
> all cases.

bio_copy_kern copies all the data, so it is generally not a good
idea.  The cache flushing isn't too hard - take a look at the XFS
buffer cache for an existing version.

It would be good to just to do the right thing inside bio_map_kern
for that so that callers don't need to care if it is vmalloced or
not.

> Ok. So this would mean that targets (e.g., pblk) deal with struct
> request instead of only dealing with bios and then letting the LightNVM
> core transforming bios to requests. This way we can directly map to the
> request. Is this what you mean?

Yes.

> Just out of curiosity, why is forming the bio trough bio_copy_kern (or
> manually doing the same) and then transforming to a request incorrect /
> worse?

Because you expose yourself to the details of mapping a bio to request.
We had to export blk_init_request_from_bio just for lightnvm to do this,
and it also has to do weird other bits about requests.  If you go
through blk_rq_map_* the block layer takes care of all that for you.

  reply	other threads:[~2017-09-07 11:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06 10:50 [PATCH 00/18] lightnvm: pblk patches for 4.14 Javier González
2017-09-06 10:50 ` [PATCH 01/18] lightnvm: pblk: improve naming for internal req Javier González
2017-09-06 13:46   ` Christoph Hellwig
2017-09-06 14:01     ` Javier González
2017-09-06 10:50 ` [PATCH 02/18] lightnvm: pblk: refactor read lba sanity check Javier González
2017-09-06 10:50 ` [PATCH 03/18] lightnvm: pblk: normalize ppa namings Javier González
2017-09-06 10:50 ` [PATCH 04/18] lightnvm: pblk: check for failed mempool alloc Javier González
2017-09-06 10:50 ` [PATCH 05/18] lightnvm: pblk: initialize debug stat counter Javier González
2017-09-06 10:50 ` [PATCH 06/18] lightnvm: pblk: use right flag for GC allocation Javier González
2017-09-06 10:51 ` [PATCH 07/18] lightnvm: pblk: use constant for GC parameter Javier González
2017-09-06 10:51 ` [PATCH 08/18] lightnvm: pblk: check lba sanity on read path Javier González
2017-09-06 10:51 ` [PATCH 09/18] lightnvm: pblk: simplify data validity check on GC Javier González
2017-09-06 10:51 ` [PATCH 10/18] lightnvm: pblk: use bio_copy_kern when possible Javier González
2017-09-06 13:47   ` Christoph Hellwig
2017-09-06 13:47     ` Christoph Hellwig
2017-09-06 14:00     ` Javier González
2017-09-07 11:08       ` Christoph Hellwig [this message]
2017-09-07 11:08         ` Christoph Hellwig
2017-09-07 11:20         ` Javier González
2017-09-06 10:51 ` [PATCH 11/18] lightnvm: pblk: refactor read path on GC Javier González
2017-09-06 10:51 ` [PATCH 12/18] lightnvm: pblk: free padded entries in write buffer Javier González
2017-09-06 10:51 ` [PATCH 13/18] lightnvm: pblk: fix write I/O sync stat Javier González
2017-09-06 10:51 ` [PATCH 14/18] lightnvm: pblk: simplify path on REQ_PREFLUSH Javier González
2017-09-06 10:51 ` [PATCH 15/18] lightnvm: pblk: avoid deadlock on low LUN config Javier González
2017-09-06 10:51 ` [PATCH 16/18] lightnvm: pblk: enable 1 LUN configuration Javier González
2017-09-06 10:51 ` [PATCH 17/18] lightnvm: pblk: guarantee line integrity on reads Javier González
2017-09-06 10:51 ` [PATCH 18/18] lightnvm: pblk: remove unnecessary check Javier González
2017-09-06 14:04 ` [PATCH 00/18] lightnvm: pblk patches for 4.14 Jens Axboe
2017-09-06 14:10   ` Javier González

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170907110801.GA17144@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@fb.com \
    --cc=jg@lightnvm.io \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matias@cnexlabs.com \
    --cc=mb@lightnvm.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.