linux.git/include/linux/blkdev.h, branch v3.1-rc1

block: strict rq_affinity

2011-07-23T18:44:25+00:00

Some systems benefit from completions always being steered to the strict
requester cpu rather than the looser "per-socket" steering that
blk_cpu_to_group() attempts by default. This is because the first
CPU in the group mask ends up being completely overloaded with work,
while the others (including the original submitter) has power left
to spare.

Allow the strict mode to be set by writing '2' to the sysfs control
file. This is identical to the scheme used for the nomerges file,
where '2' is a more aggressive setting than just being turned on.

echo 2 > /sys/block//queue/rq_affinity

Cc: Christoph Hellwig 
Cc: Roland Dreier 
Tested-by: Dave Jiang 
Signed-off-by: Dan Williams 
Signed-off-by: Jens Axboe

block: reorder request_queue to remove 64 bit alignment padding

2011-07-13T19:17:49+00:00

Reorder request_queue to remove 16 bytes of alignment padding in 64 bit
builds.

On my config this shrinks the size of this structure from 1608 to 1592
bytes and therefore needs one fewer cachelines.

Also trivially move the open bracket { to be on the same line as the
structure name to make it easier to grep.

Signed-off-by: Richard Kennedy 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe

block: document blk_plug list access

2011-07-08T06:19:21+00:00

I'm often confused why not disable preempt when changing blk_plug list. It
would be better to add comments here in case others have the similar concerns.

Signed-off-by: Shaohua Li 
Signed-off-by: Jens Axboe

block: avoid building too big plug list

2011-07-08T06:19:20+00:00

When I test fio script with big I/O depth, I found the total throughput drops
compared to some relative small I/O depth. The reason is the thread accumulates
big requests in its plug list and causes some delays (surely this depends
on CPU speed).
I thought we'd better have a threshold for requests. When a threshold reaches,
this means there is no request merge and queue lock contention isn't severe
when pushing per-task requests to queue, so the main advantages of blk plug
don't exist. We can force a plug list flush in this case.
With this, my test throughput actually increases and almost equals to small
I/O depth. Another side effect is irq off time decreases in blk_flush_plug_list()
for big I/O depth.
The BLK_MAX_REQUEST_COUNT is choosen arbitarily, but 16 is efficiently to
reduce lock contention to me. But I'm open here, 32 is ok in my test too.

Signed-off-by: Shaohua Li 
Signed-off-by: Jens Axboe

Merge branch 'for-linus' into for-3.1/core

2011-07-01T14:17:13+00:00

Conflicts:
	block/blk-throttle.c
	block/cfq-iosched.c

Signed-off-by: Jens Axboe

block:fix the comment error in blkdev.h

2011-06-13T08:45:38+00:00

There is not a function rq_init but blk_rq_init in block/blk-core.c.

Signed-off-by: Wanlong Gao 
Signed-off-by: Jens Axboe

block: remove unwanted semicolons

2011-05-31T11:45:53+00:00

Since those defined functions require additional semicolon
from the caller, they could cause potential syntax errors
when used in if-else statements.

Signed-off-by: Namhyung Kim 
Acked-by: Martin K. Petersen 
Signed-off-by: Jens Axboe

Merge commit 'v2.6.39' into for-2.6.40/core

2011-05-20T18:33:15+00:00

Since for-2.6.40/core was forked off the 2.6.39 devel tree, we've
had churn in the core area that makes it difficult to handle
patches for eg cfq or blk-throttle. Instead of requiring that they
be based in older versions with bugs that have been fixed later
in the rc cycle, merge in 2.6.39 final.

Also fixes up conflicts in the below files.

Conflicts:
	drivers/block/paride/pcd.c
	drivers/cdrom/viocd.c
	drivers/ide/ide-cd.c

Signed-off-by: Jens Axboe

block: Fix discard topology stacking and reporting

2011-05-18T08:37:35+00:00

In some cases we would end up stacking discard_zeroes_data incorrectly.
Fix this by enabling the feature by default for stacking drivers and
clearing it for low-level drivers. Incorporating a device that does not
support dzd will then cause the feature to be disabled in the stacking
driver.

Also ensure that the maximum discard value does not overflow when
exported in sysfs and return 0 in the alignment and dzd fields for
devices that don't support discard.

Reported-by: Lukas Czerner 
Signed-off-by: Martin K. Petersen 
Acked-by: Mike Snitzer 
Cc: stable@kernel.org
Signed-off-by: Jens Axboe

block: hold queue if flush is running for non-queueable flush drive

2011-05-06T17:36:25+00:00

In some drives, flush requests are non-queueable. When flush request is
running, normal read/write requests can't run. If block layer dispatches
such request, driver can't handle it and requeue it.  Tejun suggested we
can hold the queue when flush is running. This can avoid unnecessary
requeue.  Also this can improve performance. For example, we have
request flush1, write1, flush 2. flush1 is dispatched, then queue is
hold, write1 isn't inserted to queue. After flush1 is finished, flush2
will be dispatched. Since disk cache is already clean, flush2 will be
finished very soon, so looks like flush2 is folded to flush1.

In my test, the queue holding completely solves a regression introduced by
commit 53d63e6b0dfb95882ec0219ba6bbd50cde423794:

    block: make the flush insertion use the tail of the dispatch list

    It's not a preempt type request, in fact we have to insert it
    behind requests that do specify INSERT_FRONT.

which causes about 20% regression running a sysbench fileio
workload.

Stable: 2.6.39 only

Cc: stable@kernel.org
Signed-off-by: Shaohua Li 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe