search for: __make_request

...lt;7><7><7><7><7><7><7><7><7><7><7><7><7> <7><7><7><7><7>__bio_add_page: 2x ph 88>128 || hw 88>88 || 360448>max ffffffff802525d8 generic_make_request(bio 000001017c745300) 50729472, 704 __make_request(q 00000101b9293870, bio 000001017c745300: sdc; 50729600, 704) ll_new_hw_segment: 70 + 29 > 88 <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> <7>&lt...

...de> Cc: Christoph Hellwig <hch at infradead.org> --- block/blk-core.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3299a7..35ad2bb 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q, struct bio *bio) const int unplug = bio_unplug(bio); int rw_flags; - if (bio_barrier(bio) && bio_has_data(bio) && - (q->next_ordered == QUEUE_ORDERED_NONE)) { + if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) { bio...

...de> Cc: Christoph Hellwig <hch at infradead.org> --- block/blk-core.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3299a7..35ad2bb 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q, struct bio *bio) const int unplug = bio_unplug(bio); int rw_flags; - if (bio_barrier(bio) && bio_has_data(bio) && - (q->next_ordered == QUEUE_ORDERED_NONE)) { + if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) { bio...

I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and

...at redhat.com> Cc: Neil Brown <neilb at suse.de> --- block/blk-core.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3299a7..35ad2bb 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q, struct bio *bio) const int unplug = bio_unplug(bio); int rw_flags; - if (bio_barrier(bio) && bio_has_data(bio) && - (q->next_ordered == QUEUE_ORDERED_NONE)) { + if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) { bio...

...at redhat.com> Cc: Neil Brown <neilb at suse.de> --- block/blk-core.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3299a7..35ad2bb 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q, struct bio *bio) const int unplug = bio_unplug(bio); int rw_flags; - if (bio_barrier(bio) && bio_has_data(bio) && - (q->next_ordered == QUEUE_ORDERED_NONE)) { + if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) { bio...

...; c01300a9 <shrink_caches+19/90> Trace; c013015c <try_to_free_pages_zone+3c/60> Trace; c0130c52 <balance_classzone+62/200> Trace; c0130f0b <__alloc_pages+11b/170> Trace; c0136610 <alloc_bounce_page+10/a0> Trace; c013676c <create_bounce+2c/148> Trace; c01be751 <__make_request+a1/5e0> Trace; c0222e23 <net_rx_action+b3/170> Trace; c011bb0b <bh_action+4b/80> Trace; c011b9b1 <tasklet_hi_action+61/a0> Trace; c011b73b <do_softirq+6b/d0> Trace; c0108b6d <do_IRQ+dd/f0> Trace; c01bed9a <generic_make_request+10a/120> Trace; c013a636 <__re...

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

...33 houla0 <ffffffffa01ef63b>{:xfs:xfs_iread_extents +139} <ffffffffa01cffda>{:xfs:xfs_bmapi+874} Nov 7 12:50:33 houla0 <ffffffff80255cda>{cfq_add_crq_rb+128} <ffffffff8024cad8>{__elv_add_request+65} Nov 7 12:50:33 houla0 <ffffffff8024f7dd>{__make_request+1351} <ffffffffa00ab30c>{:dm_mod:__map_bio+66} Nov 7 12:50:33 houla0 <ffffffffa00ab7ef>{:dm_mod:__split_bio +1026} <ffffffff8015cb38>{mempool_alloc+129} Nov 7 12:50:33 houla0 <ffffffff801ea821>{__up_read+16} <ffffffffa00ab98a>{:dm_mod:dm_request+3...

...lock_clocksource_read+0x3a/0x8b [163440.613537] [<ffffffff8130b5f1>] ? io_schedule+0x73/0xb7 [163440.613546] [<ffffffff8118053b>] ? get_request_wait+0xf0/0x188 [163440.613553] [<ffffffff81065d0a>] ? autoremove_wake_function+0x0/0x2e [163440.613559] [<ffffffff811808ca>] ? __make_request+0x2f7/0x428 [163440.613565] [<ffffffff8117f0a7>] ? generic_make_request+0x299/0x2f9 [163440.613574] [<ffffffff81176f2d>] ? elv_rb_latter_request+0x0/0x23 [163440.613580] [<ffffffff8117f1dd>] ? submit_bio+0xd6/0xf2 [163440.613588] [<ffffffff8110dc59>] ? submit_bh+0x103/0x...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...<f8a01f6a>] zt_ioctl+0x273/0x144f [zaptel] [<c0457600>] mempool_alloc+0x28/0xc9 [<c04ddd33>] cfq_resort_rr_list+0x23/0x8b [<c04deb6c>] cfq_add_crq_rb+0xba/0xc3 [<c04dec72>] cfq_insert_request+0x42/0x498 [<c04d5175>] elv_insert+0x10a/0x1ad [<c04d908b>] __make_request+0x31d/0x366 [<c04de8b1>] cfq_dispatch_requests+0x26a/0x46b [<c04dde27>] __cfq_slice_expired+0x8c/0xa5 [<c04de8b1>] cfq_dispatch_requests+0x26a/0x46b [<c04d505d>] elv_next_request+0x15c/0x16a [<f88bc101>] start_io+0x77/0xdc [cciss] [<f88bf63e>] do_cciss_requ...

When I copy a file(13Megs) from /home/ to /tmp/, sync takes almost 2 minutes. When I copy the same file to /usr/local/, sync returns almost right away. Both filesystems are ext3 and are on the same harddrive. When sync is running, the harddrive light stays on but I don't hear it doing anything. dmesg doesn't show any errors either. Below is the `time` output for each command. If you

On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.

...0 ef08e0c0 [ 341.738435] Call Trace: [ 341.740961] [<f1d6597b>] ? scsi_dispatch_cmd+0x179/0x1e5 [scsi_mod] [ 341.747366] [<f1d6a33c>] ? scsi_request_fn+0x343/0x47a [scsi_mod] [ 341.753607] [<c1131da3>] ? __generic_unplug_device+0x23/0x25 [ 341.759410] [<c11323a4>] ? __make_request+0x364/0x3d9 [ 341.764612] [<c10066dc>] ? check_events+0x8/0xc [ 341.769290] [<c1130f81>] ? generic_make_request+0x266/0x2b4 [ 341.775009] [<c1131fd1>] ? generic_unplug_device+0x2c/0x2e [ 341.780643] [<c112b558>] ? blk_unplug+0x2e/0x31 [ 341.785323] [<f1d1ad12&gt...