On 2014-10-02 21:26, Elliott, Robert (Server Storage) wrote:
-----Original Message-----
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Mike Snitzer
Sent: Thursday, 02 October, 2014 7:11 PM
To: ax...@kernel.dk; linux-kernel@vger.kernel.org
Cc: ty...@mit.edu; gmazyl...@gmail.com; a...@redhat.com; mpato...@redhat.com
Subject: [PATCH] block: disable entropy contributions from nonrot devices
Introduce queue_flags_set_nonrot_clear_add_random() and convert all
block drivers that set QUEUE_FLAG_NONROT over to using it instead.
Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.
There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.
blk-mq defaults to off (QUEUE_FLAG_MQ_DEFAULT does not
include QUEUE_FLAG_ADD_RANDOM).
Even when it's off in block layer completion processing, all interrupts,
storage or not, are forced to contribute during hardirq processing.
I've seen this add 3-12 us latency blips every 64 interrupts (when
the "fast_mix" code runs out of bits).
Yeah, it's a well known problem, and just as large (or larger) as the
request completion randomness. It has significant performance
implications, as your trace also shows. I'm pretty sure I complained
about this 2-3 years ago (or longer), yet it's still poor.
I'd be fine with having an irq registration flag that says "don't
contribute to randomness", on the grounds of more predictable irq
latencies one these devices not adding any real entropy to the pool. But
the suboptimal mixing should really be fixed.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
