mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: scameron@beardog.cce.hp.com
To: linux-kernel@vger.kernel.org
Cc: stephenmcameron@gmail.com, scameron@beardog.cce.hp.com,
	chayan.biswas@sandisk.com, elliott@hp.com
Subject: Question about make_request_fn based block drivers
Date: Wed, 20 Mar 2013 16:58:38 -0500	[thread overview]
Message-ID: <20130320215838.GO30284@beardog.cce.hp.com> (raw)


When running mke2fs against the make_request_fn based block driver
I'm working on, I'm seeing only single-block bios.  Other such drivers
(e.g. nvme) are getting, for example, 4k bios coming in from the same
mke2fs command.

mke2fs /dev/sop0

This is on a 3.9-rc1 kernel.

I've tried setting:

	blk_queue_max_hw_sectors(rq, 2048);
	blk_queue_max_segments(rq, 32);
	blk_queue_io_opt(rq, 4096);
	blk_queue_io_min(rq, 4096);
	blk_queue_physical_block_size(rq, 4096);
	blk_queue_logical_block_size(h->rq, 512);
	blk_queue_physical_block_size(h->rq, 4096);

all to no avail.

If I do this:

	dd if=/dev/sop0 of=/dev/null bs=4k iflag=direct 

with that, I can get 4k bios coming in to the make_request_fn.

Driver source is here: https://github.com/HPSmartStorage/scsi-over-pcie
(still a work in progress -- that source doesn't do all the blk_queue_*
settings mentioned above, those are just the things I've tried.)

In /sys/block/sop0/queue...

[scameron@localhost queue]$ for x in *
> do
> echo ===== $x ======
> cat $x
> done
===== add_random ======
1
===== discard_granularity ======
0
===== discard_max_bytes ======
0
===== discard_zeroes_data ======
0
===== hw_sector_size ======
512
===== iostats ======
1
===== logical_block_size ======
512
===== max_hw_sectors_kb ======
1024
===== max_integrity_segments ======
0
===== max_sectors_kb ======
512
===== max_segments ======
32
===== max_segment_size ======
65536
===== minimum_io_size ======
4096
===== nomerges ======
2
===== nr_requests ======
128
===== optimal_io_size ======
4096
===== physical_block_size ======
4096
===== read_ahead_kb ======
128
===== rotational ======
0
===== rq_affinity ======
1
===== scheduler ======
none
===== write_same_max_bytes ======
0
[scameron@localhost queue]$

Any ideas what I'm missing to get I/O's bigger than 1 block to come in?

Thanks,

-- steve


             reply	other threads:[~2013-03-20 21:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 21:58 scameron [this message]
2013-03-20 22:01 ` Chayan Biswas
2013-03-20 22:21   ` scameron
2013-03-20 22:28     ` Chayan Biswas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130320215838.GO30284@beardog.cce.hp.com \
    --to=scameron@beardog.cce.hp.com \
    --cc=chayan.biswas@sandisk.com \
    --cc=elliott@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stephenmcameron@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®