search for: end_io

V1->V2: -Changed dio_end_io to EXPORT_SYMBOL_GPL -Removed the own_submit blockdev dio helper -Removed the boundary change V2->V3 -Made it so we keep track of what the current logical offset in the file we have a BIO setup for so we can pass it into the submit_io hook. Because BTRFS can do RAID and such, we need our own s...

...ownload v0.12 here: http://oss.oracle.com/projects/btrfs Other changes: Insert and delete multiple items at once in the btree where possible. Back references added more tree balances, and it showed up in a few benchmarks. With v0.12, backrefs have no real impact on performance. Optimize bio end_io routines. Btrfs was spending way too much CPU time in the bio end_io routines, leading to lock contention and other problems. Optimize read ahead during transaction commit. The old code was trying to read far too much at once, which made the end_io problems really stand out. mount -o ssd opti...

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

...39;ve had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > from IRQ context is causing the issue. > IIUC you switched virtio to this from __blk_end_request_all in > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > virtio_blk: blk-mq support > > Is this always safe? > I note that at least one other driver is doing this: &g...

...39;ve had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > from IRQ context is causing the issue. > IIUC you switched virtio to this from __blk_end_request_all in > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > virtio_blk: blk-mq support > > Is this always safe? > I note that at least one other driver is doing this: &g...

...e of ext4_page_mkwrite - do not use wait_on_bit, but replace it with an opencoded hashed waitqueue - rename inode_dio_wake to inode_dio_done - add kerneldoc comments for inode_dio_wait and inode_dio_done - simplify the blockdev_direct_IO prototype - move the i_dio_count decrement into the ->end_io handler if present to make i_dio_count useful for filesystems delaying AIO completion - reorder the patch series - patches 1 to 5 are the meat, the rest is additonal tidyups in that area required for future improvements -- To unsubscribe from this list: send the line "unsubscribe linux-...

...] of the virt_blk driver causing a lot of spew > > > because it's calling a sleeping function from an invalid context. The > > > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. > > > > Hi Jens, pls see below - it looks like the call to blk_mq_end_io > > from IRQ context is causing the issue. > > IIUC you switched virtio to this from __blk_end_request_all in > > > > commit 1cf7e9c68fe84248174e998922b39e508375e7c1 > > virtio_blk: blk-mq support > > > > Is this always safe? > > I note that at...

...ed first_block_in_page; /* doesn''t change, Used only once */ int boundary; /* prev block is at a boundary */ + int separate_meta_reads; /* separate in I/O submission */ int reap_counter; /* rate limit reaping */ get_block_t *get_block; /* block mapping function */ dio_iodone_t *end_io; /* IO completion function */ @@ -659,7 +661,7 @@ static int dio_send_cur_page(struct dio *dio) * Submit now if the underlying fs is about to perform a * metadata read */ - else if (dio->boundary) + else if (dio->separate_meta_reads && dio->boundary) dio_bio_sub...

...virt_blk driver causing a lot of spew >>>> because it's calling a sleeping function from an invalid context. The >>>> backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. >>> >>> Hi Jens, pls see below - it looks like the call to blk_mq_end_io >>> from IRQ context is causing the issue. >>> IIUC you switched virtio to this from __blk_end_request_all in >>> >>> commit 1cf7e9c68fe84248174e998922b39e508375e7c1 >>> virtio_blk: blk-mq support >>> >>> Is this always safe? >&g...

...virt_blk driver causing a lot of spew >>>> because it's calling a sleeping function from an invalid context. The >>>> backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. >>> >>> Hi Jens, pls see below - it looks like the call to blk_mq_end_io >>> from IRQ context is causing the issue. >>> IIUC you switched virtio to this from __blk_end_request_all in >>> >>> commit 1cf7e9c68fe84248174e998922b39e508375e7c1 >>> virtio_blk: blk-mq support >>> >>> Is this always safe? >&g...

(cc''ing btrfs people) On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote: > RIP: 0010:[<ffffffff812484d3>] [<ffffffff812484d3>] ftrace_raw_event_block_bio_complete+0x73/0xf0 ... > [<ffffffff811b6c10>] bio_endio+0x80/0x90 > [<ffffffffa0790d26>] btrfs_end_bio+0xf6/0x190 [btrfs] > [<ffffffff811b6bcd>] bio_endio+0x3d/0x90 >

...+0x93/0xb0 [raid1] [<ffffffffa00df029>] r1_bio_write_done+0x29/0x50 [raid1] [<ffffffffa00e0474>] raid1_end_write_request+0xe4/0x260 [raid1] [<ffffffff813acb8b>] bio_endio+0x6b/0xa0 [<ffffffff813b46c4>] blk_update_request+0x94/0x420 [<ffffffff813bf0ea>] blk_mq_end_io+0x1a/0x70 [<ffffffffa00392c2>] virtblk_request_done+0x32/0x80 [virtio_blk] [<ffffffff813c0648>] __blk_mq_complete_request+0x88/0x120 [<ffffffff813c070a>] blk_mq_complete_request+0x2a/0x30 [<ffffffffa0039066>] virtblk_done+0x66/0xe0 [virtio_blk] [<ffffffffa002535...

...+0x93/0xb0 [raid1] [<ffffffffa00df029>] r1_bio_write_done+0x29/0x50 [raid1] [<ffffffffa00e0474>] raid1_end_write_request+0xe4/0x260 [raid1] [<ffffffff813acb8b>] bio_endio+0x6b/0xa0 [<ffffffff813b46c4>] blk_update_request+0x94/0x420 [<ffffffff813bf0ea>] blk_mq_end_io+0x1a/0x70 [<ffffffffa00392c2>] virtblk_request_done+0x32/0x80 [virtio_blk] [<ffffffff813c0648>] __blk_mq_complete_request+0x88/0x120 [<ffffffff813c070a>] blk_mq_complete_request+0x2a/0x30 [<ffffffffa0039066>] virtblk_done+0x66/0xe0 [virtio_blk] [<ffffffffa002535...

...; req->cmd_type == REQ_TYPE_FS) - laptop_io_completion(&req->q->backing_dev_info); + laptop_io_completion(&q->backing_dev_info); blk_delete_timer(req); if (req->cmd_flags & REQ_DONTPREP) blk_unprep_request(req); blk_account_io_done(req); if (req->end_io) req->end_io(req, error); else { if (blk_bidi_rq(req)) - __blk_put_request(req->next_rq->q, req->next_rq); + __blk_put_request(req->next_rq); - __blk_put_request(req->q, req); + __blk_put_request(req); } } /** * blk_end_bidi_request - Complete a bidi reques...

...; req->cmd_type == REQ_TYPE_FS) - laptop_io_completion(&req->q->backing_dev_info); + laptop_io_completion(&q->backing_dev_info); blk_delete_timer(req); if (req->cmd_flags & REQ_DONTPREP) blk_unprep_request(req); blk_account_io_done(req); if (req->end_io) req->end_io(req, error); else { if (blk_bidi_rq(req)) - __blk_put_request(req->next_rq->q, req->next_rq); + __blk_put_request(req->next_rq); - __blk_put_request(req->q, req); + __blk_put_request(req); } } /** * blk_end_bidi_request - Complete a bidi reques...

On 06/27/2011 07:46 AM, NeilBrown wrote: > On Thu, 23 Jun 2011 12:53:37 +0200 Nico Schottelius > <nico-lkml-20110623@schottelius.org> wrote: > >> Good morning devs, >> >> I''m wondering whether the raid- and volume-management-builtin of btrfs is >> actually a sane idea or not. >> Currently we do have md/device-mapper support for raid >>

Hi everyone, This is dm-ioband version 1.0.0 release. Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on the same physical device. - Can be applied to the kernel 2.6.26-rc2-mm1. - Changes from 0.0.4 (24th April): - Performance tuning - A new bandwidth control policy is added. This policy controls

Hi everyone, This is dm-ioband version 1.0.0 release. Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on the same physical device. - Can be applied to the kernel 2.6.26-rc2-mm1. - Changes from 0.0.4 (24th April): - Performance tuning - A new bandwidth control policy is added. This policy controls

Hi everyone, This is dm-ioband version 1.0.0 release. Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on the same physical device. - Can be applied to the kernel 2.6.26-rc2-mm1. - Changes from 0.0.4 (24th April): - Performance tuning - A new bandwidth control policy is added. This policy controls

In blkback driver, after I/O requests are submitted to Dom-0 block I/O subsystem, blkback goes to ''sleep'' effectively without letting blkfront know about it (req_event isn''t set appropriately). Hence blkfront doesn''t notify blkback when it submits a new I/O thus delaying the ''dispatch'' of the new I/O to Dom-0 block I/O subsystem. The new I/O is