On 9/28/22 11:31 AM, Christoph Hellwig wrote: > On Tue, Sep 27, 2022 at 11:06:08PM +0530, Kanchan Joshi wrote: >> Move bio allocation logic from bio_map_user_iov to a new helper >> bio_map_get. It is named so because functionality is opposite of what is >> done inside bio_map_put. This is a prep patch. > > I'm still not a fan of using bio_sets for passthrough and would be > much happier if we could drill down what the problems with the > slab per-cpu allocator are, but it seems like I've lost that fight > against Jens.. I don't think there are necessarily big problems with the slab side, it's just that the per-cpu freeing there needs to be IRQ safe. And the double cmpxchg() used for that isn't that fast compared to being able to cache these locally with just preempt protection. >> +static struct bio *bio_map_get(struct request *rq, unsigned int nr_vecs, >> gfp_t gfp_mask) > > But these names just seems rather misleading. Why not someting > like blk_rq_map_bio_alloc and blk_mq_map_bio_put? > > Not really new in this code but a question to Jens: The existing > bio_map_user_iov has no real upper bounds on the number of bios > allocated, how does that fit with the very limited pool size of > fs_bio_set? Good question - I think we'd need to ensure that once we get past the initial alloc that we clear any gfp flags that'd make the mempool_alloc() wait for completions. -- Jens Axboe
