Re: Re: scsi-mq + open-iscsi support patches..?
Hi all， I used target-pending/scsi-mq to test intel ahci，but it can't work.I modify some places, now it can work.But still met hung task or oops. Who can receive my patch for that? Thanks! Jianpeng Ma >On Sat, 2013-11-02 at 16:10 +, Jayamohan Kallickal wrote: > > > >> >> On a related note, some iscsi vendor has been hitting a crash with >> >> your tree. >> >> >I got an email from Jayamohan recently, but the OOPs did not appear to be >> >scsi-mq related.. >> >> I do see the crash on my Ubuntu VM running on VirtualBox but don't see the >> crash on a Standalone system. >> Attaching the screenshot >> > >Hi Jayamohan, > >Care to enable the virtual serial port for this VM in order to grab the >full dmesg output..? > >Also, an idea of what SATA emulation is being used here would be helpful >as well. (eg: lspci -vvv for the ATA device on the running system) > >--nab > >-- >To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: scsi-mq + open-iscsi support patches..?
Hi all， I used target-pending/scsi-mq to test intel ahci，but it can't work.I modify some places, now it can work.But still met hung task or oops. Who can receive my patch for that? Thanks! Jianpeng Ma On Sat, 2013-11-02 at 16:10 +, Jayamohan Kallickal wrote: SNIP On a related note, some iscsi vendor has been hitting a crash with your tree. I got an email from Jayamohan recently, but the OOPs did not appear to be scsi-mq related.. I do see the crash on my Ubuntu VM running on VirtualBox but don't see the crash on a Standalone system. Attaching the screenshot Hi Jayamohan, Care to enable the virtual serial port for this VM in order to grab the full dmesg output..? Also, an idea of what SATA emulation is being used here would be helpful as well. (eg: lspci -vvv for the ATA device on the running system) --nab -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH 3/3] md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.
>On Wed, 30 Oct 2013 10:41:46 +0800 majianpeng wrote: > >> For R5_ReadNoMerge,it mean this bio can't merge with other bios or >> request.It used REQ_FLUSH to achieve this. But REQ_NOMERGE can do the >> same work. >> >> Signed-off-by: Jianpeng Ma >> --- >> drivers/md/raid5.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c >> index f8b9068..8e0aeaa 100644 >> --- a/drivers/md/raid5.c >> +++ b/drivers/md/raid5.c >> @@ -772,7 +772,7 @@ static void ops_run_io(struct stripe_head *sh, struct >> stripe_head_state *s) >> bi->bi_sector = (sh->sector >> + rdev->data_offset); >> if (test_bit(R5_ReadNoMerge, >dev[i].flags)) >> -bi->bi_rw |= REQ_FLUSH; >> +bi->bi_rw |= REQ_NOMERGE; >> >> bi->bi_vcnt = 1; >> bi->bi_io_vec[0].bv_len = STRIPE_SIZE; > >Thanks. > >I've queued this up pending Jens' acceptance of the other patches. > >By the way, your patch file has a carriage return as well as a newline at the >end of each line. >"patch" can still handle them but "git am" doesn't like it. > >If you are able to send the patches as plain text with just a NEWLINE at the >end of each line, rather than base64 encodes with carriage returns, it would >help a little. > Sorroy for that, i'll pay attention to this. Thanks! Jianpeng Ma >Thanks, >NeilBrown >
Re: Re: [PATCH 3/3] md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.
On Wed, 30 Oct 2013 10:41:46 +0800 majianpeng majianp...@gmail.com wrote: For R5_ReadNoMerge,it mean this bio can't merge with other bios or request.It used REQ_FLUSH to achieve this. But REQ_NOMERGE can do the same work. Signed-off-by: Jianpeng Ma majianp...@gmail.com --- drivers/md/raid5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index f8b9068..8e0aeaa 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -772,7 +772,7 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s) bi-bi_sector = (sh-sector + rdev-data_offset); if (test_bit(R5_ReadNoMerge, sh-dev[i].flags)) -bi-bi_rw |= REQ_FLUSH; +bi-bi_rw |= REQ_NOMERGE; bi-bi_vcnt = 1; bi-bi_io_vec[0].bv_len = STRIPE_SIZE; Thanks. I've queued this up pending Jens' acceptance of the other patches. By the way, your patch file has a carriage return as well as a newline at the end of each line. patch can still handle them but git am doesn't like it. If you are able to send the patches as plain text with just a NEWLINE at the end of each line, rather than base64 encodes with carriage returns, it would help a little. Sorroy for that, i'll pay attention to this. Thanks! Jianpeng Ma Thanks, NeilBrown
Re: Re: O_DIRECT to md raid 6 is slow
On 2012-08-15 09:12 Andy Lutomirski Wrote:
>Ubuntu's 3.2.0-27-generic. I can test on a newer kernel tomorrow.
I guess maybe miss the blk_plug function.
Can you add this patch and retest.
Move unplugging for direct I/O from around ->direct_IO() down to
do_blockdev_direct_IO(). This implicitly adds plugging for direct
writes.
CC: Li Shaohua
Acked-by: Jeff Moyer
Signed-off-by: Wu Fengguang
---
fs/direct-io.c |5 +
mm/filemap.c |4
2 files changed, 5 insertions(+), 4 deletions(-)
--- linux-next.orig/mm/filemap.c 2012-08-05 16:24:47.859465122 +0800
+++ linux-next/mm/filemap.c 2012-08-05 16:24:48.407465135 +0800
@@ -1412,12 +1412,8 @@ generic_file_aio_read(struct kiocb *iocb
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
- struct blk_plug plug;
-
- blk_start_plug();
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
- blk_finish_plug();
}
if (retval > 0) {
*ppos = pos + retval;
--- linux-next.orig/fs/direct-io.c 2012-07-07 21:46:39.531508198 +0800
+++ linux-next/fs/direct-io.c 2012-08-05 16:24:48.411465136 +0800
@@ -1062,6 +1062,7 @@ do_blockdev_direct_IO(int rw, struct kio
unsigned long user_addr;
size_t bytes;
struct buffer_head map_bh = { 0, };
+ struct blk_plug plug;
if (rw & WRITE)
rw = WRITE_ODIRECT;
@@ -1177,6 +1178,8 @@ do_blockdev_direct_IO(int rw, struct kio
PAGE_SIZE - user_addr / PAGE_SIZE);
}
+ blk_start_plug();
+
for (seg = 0; seg < nr_segs; seg++) {
user_addr = (unsigned long)iov[seg].iov_base;
sdio.size += bytes = iov[seg].iov_len;
@@ -1235,6 +1238,8 @@ do_blockdev_direct_IO(int rw, struct kio
if (sdio.bio)
dio_bio_submit(dio, );
+ blk_finish_plug();
+
/*
* It is possible that, we return short IO due to end of file.
* In that case, we need to release all the pages we got hold on.
--
Re: O_DIRECT to md raid 6 is slow
On 2012-08-15 08:49 Andy Lutomirski Wrote:
>If I do:
># dd if=/dev/zero of=/dev/md0p1 bs=8M
>then iostat -m 5 says:
>
>avg-cpu: %user %nice %system %iowait %steal %idle
> 0.000.00 26.88 35.270.00 37.85
>
>Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
>sdb 265.20 1.1654.79 5273
>sdc 266.20 1.4754.73 7273
>sdd 264.20 1.3854.54 6272
>sdf 286.00 1.8454.74 9273
>sde 266.60 1.0454.75 5273
>sdg 265.00 1.0254.74 5273
>md0 55808.00 0.00 218.00 0 1090
>
>If I do:
># dd if=/dev/zero of=/dev/md0p1 bs=8M oflag=direct
>then iostat -m 5 says:
>avg-cpu: %user %nice %system %iowait %steal %idle
> 0.000.00 11.70 12.940.00 75.36
>
>Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
>sdb 831.00 8.5830.42 42152
>sdc 832.80 8.0529.99 40149
>sdd 832.00 9.1029.78 45148
>sdf 838.40 9.1129.72 45148
>sde 828.80 7.9129.79 39148
>sdg 850.80 8.0030.18 40150
>md01012.60 0.00 101.27 0506
>
>It looks like md isn't recognizing that I'm writing whole stripes when
>I'm in O_DIRECT mode.
>
kernel version?
>--Andy
>
>--
>Andy Lutomirski
>AMA Capital Management, LLC
>--
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at
>http://vger.kernel.org/majordomo-info.htmlN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
> 0鹅h���i
Re: O_DIRECT to md raid 6 is slow
On 2012-08-15 08:49 Andy Lutomirski l...@amacapital.net Wrote:
If I do:
# dd if=/dev/zero of=/dev/md0p1 bs=8M
then iostat -m 5 says:
avg-cpu: %user %nice %system %iowait %steal %idle
0.000.00 26.88 35.270.00 37.85
Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sdb 265.20 1.1654.79 5273
sdc 266.20 1.4754.73 7273
sdd 264.20 1.3854.54 6272
sdf 286.00 1.8454.74 9273
sde 266.60 1.0454.75 5273
sdg 265.00 1.0254.74 5273
md0 55808.00 0.00 218.00 0 1090
If I do:
# dd if=/dev/zero of=/dev/md0p1 bs=8M oflag=direct
then iostat -m 5 says:
avg-cpu: %user %nice %system %iowait %steal %idle
0.000.00 11.70 12.940.00 75.36
Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sdb 831.00 8.5830.42 42152
sdc 832.80 8.0529.99 40149
sdd 832.00 9.1029.78 45148
sdf 838.40 9.1129.72 45148
sde 828.80 7.9129.79 39148
sdg 850.80 8.0030.18 40150
md01012.60 0.00 101.27 0506
It looks like md isn't recognizing that I'm writing whole stripes when
I'm in O_DIRECT mode.
kernel version?
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to majord...@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.htmlN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: Re: O_DIRECT to md raid 6 is slow
On 2012-08-15 09:12 Andy Lutomirski l...@amacapital.net Wrote:
Ubuntu's 3.2.0-27-generic. I can test on a newer kernel tomorrow.
I guess maybe miss the blk_plug function.
Can you add this patch and retest.
Move unplugging for direct I/O from around -direct_IO() down to
do_blockdev_direct_IO(). This implicitly adds plugging for direct
writes.
CC: Li Shaohua s...@fusionio.com
Acked-by: Jeff Moyer jmo...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
fs/direct-io.c |5 +
mm/filemap.c |4
2 files changed, 5 insertions(+), 4 deletions(-)
--- linux-next.orig/mm/filemap.c 2012-08-05 16:24:47.859465122 +0800
+++ linux-next/mm/filemap.c 2012-08-05 16:24:48.407465135 +0800
@@ -1412,12 +1412,8 @@ generic_file_aio_read(struct kiocb *iocb
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
- struct blk_plug plug;
-
- blk_start_plug(plug);
retval = mapping-a_ops-direct_IO(READ, iocb,
iov, pos, nr_segs);
- blk_finish_plug(plug);
}
if (retval 0) {
*ppos = pos + retval;
--- linux-next.orig/fs/direct-io.c 2012-07-07 21:46:39.531508198 +0800
+++ linux-next/fs/direct-io.c 2012-08-05 16:24:48.411465136 +0800
@@ -1062,6 +1062,7 @@ do_blockdev_direct_IO(int rw, struct kio
unsigned long user_addr;
size_t bytes;
struct buffer_head map_bh = { 0, };
+ struct blk_plug plug;
if (rw WRITE)
rw = WRITE_ODIRECT;
@@ -1177,6 +1178,8 @@ do_blockdev_direct_IO(int rw, struct kio
PAGE_SIZE - user_addr / PAGE_SIZE);
}
+ blk_start_plug(plug);
+
for (seg = 0; seg nr_segs; seg++) {
user_addr = (unsigned long)iov[seg].iov_base;
sdio.size += bytes = iov[seg].iov_len;
@@ -1235,6 +1238,8 @@ do_blockdev_direct_IO(int rw, struct kio
if (sdio.bio)
dio_bio_submit(dio, sdio);
+ blk_finish_plug(plug);
+
/*
* It is possible that, we return short IO due to end of file.
* In that case, we need to release all the pages we got hold on.
--
