All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Xuewei Zhang" <xueweiz@google.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	ming.lei@redhat.com, hare@suse.de, hch@lst.de,
	pbonzini@redhat.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Aditya Kali" <adityakali@google.com>,
	groeck@chromium.org, "Maciej Żenczykowski" <maze@google.com>
Subject: Re: [PATCH] scsi: sd: Contribute to randomness when running rotational device
Date: Fri, 7 Sep 2018 21:06:57 -0700	[thread overview]
Message-ID: <26273801-8dd5-983a-ef09-f8eef21749ac@acm.org> (raw)
In-Reply-To: <CAPtwhKoFE-eZcRkvhpJgyutGK91ZouwSjTRb-cwHLQjBkriksw@mail.gmail.com>

On 09/06/18 16:03, Xuewei Zhang wrote:
> On Thu, Sep 6, 2018 at 3:42 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>> There was a discussion about a number of *years* ago; blk-mq has been
>> baking for a very long time.  In the early days of block_mq, the
>> overwhelming percentage of the users of blk-mq where those who were
>> using PCIe attached flash.  So when, I raised this question, the
>> argument was that SSD users have no entropy.  Which I agree with; but
>> now that blk-mq is the default, and hard drives are using blk-mq, it's
>> time for a patch like Xuewei's.
>
> Besides Ted's point of "SSD users have no entropy", I think there are
> two more reasons:
> 1. setting QUEUE_FLAG_ADD_RANDOM has a more visible performance hit
> on SSD disks than rotational disks.
> 2. SSD disks provide less entropy than rotational disks.
> I actually experimented on Container-Optimized OS, running on Google
> Compute Engine with QUEUE_FLAG_ADD_RANDOM set.
> Turns out the VM will have ~800 bit of entropy provided on boot on
> rotational disk;
> and will only have ~70 bit of entropy if running on SSD (and remember
> there are ~50 bit contributed from other sources).
> (in the above experiment, both disks were virtualized disks)

All of the above makes sense to me and is much less risky than changing
QUEUE_FLAG_MQ_DEFAULT. Hence:

Reviewed-by: Bart Van Assche <bvanassche@acm.org>


  reply	other threads:[~2018-09-08  4:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 20:37 [PATCH] scsi: sd: Contribute to randomness when running rotational device Xuewei Zhang
2018-09-06 22:27 ` Bart Van Assche
2018-09-06 22:42   ` Theodore Y. Ts'o
2018-09-06 23:03     ` Xuewei Zhang
2018-09-08  4:06       ` Bart Van Assche [this message]
2018-09-09 11:52 ` Ming Lei
2018-09-14  5:05   ` Maciej Żenczykowski
2018-09-17  6:58 ` Martin K. Petersen

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=26273801-8dd5-983a-ef09-f8eef21749ac@acm.org \
    --to=bvanassche@acm.org \
    --cc=adityakali@google.com \
    --cc=groeck@chromium.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=maze@google.com \
    --cc=ming.lei@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tytso@mit.edu \
    --cc=xueweiz@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.