search for: mempool_alloc

...diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 2edfb5c..457db0c 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -90,10 +90,11 @@ static inline struct virtblk_req *virtblk_alloc_req(struct virtio_blk *vblk, struct virtblk_req *vbr; vbr = mempool_alloc(vblk->pool, gfp_mask); - if (vbr && use_bio) - sg_init_table(vbr->sg, vblk->sg_elems); + if (!vbr) + return NULL; - vbr->vblk = vblk; + if (use_bio) + sg_init_table(vbr->sg, vblk->sg_elems); return vbr; }

...diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 2edfb5c..457db0c 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -90,10 +90,11 @@ static inline struct virtblk_req *virtblk_alloc_req(struct virtio_blk *vblk, struct virtblk_req *vbr; vbr = mempool_alloc(vblk->pool, gfp_mask); - if (vbr && use_bio) - sg_init_table(vbr->sg, vblk->sg_elems); + if (!vbr) + return NULL; - vbr->vblk = vblk; + if (use_bio) + sg_init_table(vbr->sg, vblk->sg_elems); return vbr; }

...; +static void do_virtblk_request(request_queue_t *q) > +{ > + struct virtio_blk *vblk = NULL; > + struct request *req; > + struct virtblk_req *vbr; > + > + while ((req = elv_next_request(q)) != NULL) { > + vblk = req->rq_disk->private_data; > + > + vbr = mempool_alloc(vblk->pool, GFP_ATOMIC); > + if (!vbr) > + goto stop; > + > + BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg)); > + vbr->req = req; > + if (!do_req(q, vblk, vbr)) > + goto stop; > + blkdev_dequeue_request(req); > + } > + > +syn...

...; +static void do_virtblk_request(request_queue_t *q) > +{ > + struct virtio_blk *vblk = NULL; > + struct request *req; > + struct virtblk_req *vbr; > + > + while ((req = elv_next_request(q)) != NULL) { > + vblk = req->rq_disk->private_data; > + > + vbr = mempool_alloc(vblk->pool, GFP_ATOMIC); > + if (!vbr) > + goto stop; > + > + BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg)); > + vbr->req = req; > + if (!do_req(q, vblk, vbr)) > + goto stop; > + blkdev_dequeue_request(req); > + } > + > +syn...

...el: Badness in blk_plug_device at drivers/block/ll_rw_blk.c:1217 Nov 1 13:52:13 localhost kernel: [blk_plug_device+128/144] blk_plug_device+0x80/0x90 Nov 1 13:52:13 localhost kernel: [pg0+140817474/1002423296] drbd_make_request_common+0x6f2/0x8a0 [drbd] Nov 1 13:52:13 localhost kernel: [mempool_alloc+115/432] mempool_alloc+0x73/0x1b0 Nov 1 13:52:13 localhost kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 Nov 1 13:52:13 localhost kernel: [pg0+140818108/1002423296] drbd_make_request_26+0xcc/0x27d [drbd] Nov 1 13:52:13 localhost kernel: [autoremove_wake_funct...

...P_NOFS) == GFP_NOFS) 3400 mask = GFP_NOFS; will not work and passes unfiltered flags further resulting in crash at mm/slab.c:2963 [<000000000024ae4c>] cache_alloc_refill+0x3b4/0x5c8 [<000000000024c810>] kmem_cache_alloc+0x204/0x294 [<00000000001fd3c2>] mempool_alloc+0x52/0x170 [<000003c000ced0b0>] alloc_extent_state+0x40/0xd4 [btrfs] [<000003c000cee5ae>] __clear_extent_bit+0x38a/0x4cc [btrfs] [<000003c000cee78c>] try_release_extent_state+0x9c/0xd4 [btrfs] [<000003c000cc4c66>] btree_releasepage+0x7e/0xd0 [btrfs] [<0000000000210d8...

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

...es I do _agree_ gfp flags are a mess which is really hard to get fixed > because they are lacking a good design from the very beginning. Fixing > some of those issues today is a completely PITA. It may sleep, but if it sleeps regularly, it slows down swapping (because the swapping code does mempool_alloc and mempool_alloc does __GFP_NORETRY allocation). And there were two INTENTIONAL sleeps with schedule_timeout. You removed one and left the other, claiming that __GFP_NORETRY allocation should sleep. > > > I already said that we can change it from CONFIG_DEBUG_VM to > > > CON...

...es I do _agree_ gfp flags are a mess which is really hard to get fixed > because they are lacking a good design from the very beginning. Fixing > some of those issues today is a completely PITA. It may sleep, but if it sleeps regularly, it slows down swapping (because the swapping code does mempool_alloc and mempool_alloc does __GFP_NORETRY allocation). And there were two INTENTIONAL sleeps with schedule_timeout. You removed one and left the other, claiming that __GFP_NORETRY allocation should sleep. > > > I already said that we can change it from CONFIG_DEBUG_VM to > > > CON...

...0:36:40 localhost kernel:        c015c1b5 00000010 00000001 00000000 ccced020 00000000 00000008 00000001 Oct 28 10:36:40 localhost kernel:        cc033d3c c02c46c2 cbcc5ebc 00000010 12a19620 00000010 cb248cfc c02c4983 Oct 28 10:36:40 localhost kernel: Call Trace: Oct 28 10:36:40 localhost kernel:  [mempool_alloc+115/432] mempool_alloc+0x73/0x1b0 Oct 28 10:36:40 localhost kernel:  [bio_clone+37/192] bio_clone+0x25/0xc0 Oct 28 10:36:40 localhost kernel:  [clone_bio+50/96] clone_bio+0x32/0x60 Oct 28 10:36:40 localhost kernel:  [__clone_and_map+659/704] __clone_and_map+0x293/0x2c0 Oct 28 10:36:40 localhost ker...

...c846e118 c846e120 c0463c6b Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: dc539c40 c0463ed0 00000000 00011270 dc539c68 dc539c78 e0dc23a6 01c7b000 Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: Call Trace: Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [mempool_alloc_slab+14/16] ? mempool_alloc_slab+0xe/0x10 Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [mempool_alloc+66/224] ? mempool_alloc+0x42/0xe0 Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc23a6>] ? set_extent_bit+0xa3/0x337 [btrfs] Message from syslogd@btrfs at...

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential

...fff8800cdacae40 ffffffff8117eb5a 770 Mar 23 14:27:37 sMaster01 kernel: [241450.356993] Call Trace: 771 Mar 23 14:27:37 sMaster01 kernel: [241450.357021] [<ffffffff8117eb5a>] ? generic_make_request+0xcd/0x2f9 772 Mar 23 14:27:37 sMaster01 kernel: [241450.357058] [<ffffffff810b6034>] ? mempool_alloc+0x55/0x106 773 Mar 23 14:27:37 sMaster01 kernel: [241450.357091] [<ffffffff8117ee5c>] ? submit_bio+0xd6/0xf2 774 Mar 23 14:27:37 sMaster01 kernel: [241450.357125] [<ffffffff8110d83f>] ? submit_bh+0xf5/0x115 775 Mar 23 14:27:37 sMaster01 kernel: [241450.357158] [<ffffffff8110edc0&g...

Hi, Jens & Rusty This version is rebased against linux-next which resolves the conflict with Paolo Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' patch. Patch 1/3 and 2/3 applies on linus's master as well. Since Rusty will pick up patch 3/3 so the changes to block core (adding blk_bio_map_sg()) will have a user. Jens, could you please

Hi, Jens & Rusty This version is rebased against linux-next which resolves the conflict with Paolo Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' patch. Patch 1/3 and 2/3 applies on linus's master as well. Since Rusty will pick up patch 3/3 so the changes to block core (adding blk_bio_map_sg()) will have a user. Jens, could you please

On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > No way. This is just wrong! First of all, you will explode most likely > > > > on many allocations of small sizes. Second,