> On 7 Sep 2017, at 13.08, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > 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. Yes. That would help. I know md also needs to manually add pages on vmalloced memory. Probably other do too. > >> 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. Ok. It makes sense. I'll talk to Matias about it. Thanks! Javier
Attachment:
signature.asc
Description: Message signed with OpenPGP
