1. 19 10月, 2018 2 次提交
  2. 17 10月, 2018 1 次提交
  3. 16 10月, 2018 22 次提交
  4. 15 10月, 2018 6 次提交
  5. 14 10月, 2018 5 次提交
    • J
      blk-mq: fallback to previous nr_hw_queues when updating fails · e01ad46d
      Jianchao Wang 提交于
      When we try to increate the nr_hw_queues, we may fail due to
      shortage of memory or other reason, then blk_mq_realloc_hw_ctxs stops
      and some entries in q->queue_hw_ctx are left with NULL. However,
      because queue map has been updated with new nr_hw_queues, some cpus
      have been mapped to hw queue which just encounters allocation failure,
      thus blk_mq_map_queue could return NULL. This will cause panic in
      following blk_mq_map_swqueue.
      
      To fix it, when increase nr_hw_queues fails, fallback to previous
      nr_hw_queues and post warning. At the same time, driver's .map_queues
      usually use completion irq affinity to map hw and cpu, fallback
      nr_hw_queues will cause lack of some cpu's map to hw, so use default
      blk_mq_map_queues to do that.
      
      Reported-by: syzbot+83e8cbe702263932d9d4@syzkaller.appspotmail.com
      Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      e01ad46d
    • J
      blk-mq: realloc hctx when hw queue is mapped to another node · 34d11ffa
      Jianchao Wang 提交于
      When the hw queues and mq_map are updated, a hctx could be mapped
      to a different numa node. At this moment, we need to realloc the
      hctx. If fail to do that, go on using previous hctx.
      Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      34d11ffa
    • J
      blk-mq: change gfp flags to GFP_NOIO in blk_mq_realloc_hw_ctxs · 5b202853
      Jianchao Wang 提交于
      blk_mq_realloc_hw_ctxs could be invoked during update hw queues.
      At the momemt, IO is blocked. Change the gfp flags from GFP_KERNEL
      to GFP_NOIO to avoid forever hang during memory allocation in
      blk_mq_realloc_hw_ctxs.
      Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      5b202853
    • J
      blk-mq: adjust debugfs and sysfs register when updating nr_hw_queues · 477e19de
      Jianchao Wang 提交于
      blk-mq debugfs and sysfs entries need to be removed before updating
      queue map, otherwise, we get get wrong result there. This patch fixes
      it and remove the redundant debugfs and sysfs register/unregister
      operations during __blk_mq_update_nr_hw_queues.
      Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      477e19de
    • F
      block, bfq: improve asymmetric scenarios detection · 2d29c9f8
      Federico Motta 提交于
      bfq defines as asymmetric a scenario where an active entity, say E
      (representing either a single bfq_queue or a group of other entities),
      has a higher weight than some other entities.  If the entity E does sync
      I/O in such a scenario, then bfq plugs the dispatch of the I/O of the
      other entities in the following situation: E is in service but
      temporarily has no pending I/O request.  In fact, without this plugging,
      all the times that E stops being temporarily idle, it may find the
      internal queues of the storage device already filled with an
      out-of-control number of extra requests, from other entities. So E may
      have to wait for the service of these extra requests, before finally
      having its own requests served. This may easily break service
      guarantees, with E getting less than its fair share of the device
      throughput.  Usually, the end result is that E gets the same fraction of
      the throughput as the other entities, instead of getting more, according
      to its higher weight.
      
      Yet there are two other more subtle cases where E, even if its weight is
      actually equal to or even lower than the weight of any other active
      entities, may get less than its fair share of the throughput in case the
      above I/O plugging is not performed:
      1. other entities issue larger requests than E;
      2. other entities contain more active child entities than E (or in
         general tend to have more backlog than E).
      
      In the first case, other entities may get more service than E because
      they get larger requests, than those of E, served during the temporary
      idle periods of E.  In the second case, other entities get more service
      because, by having many child entities, they have many requests ready
      for dispatching while E is temporarily idle.
      
      This commit addresses this issue by extending the definition of
      asymmetric scenario: a scenario is asymmetric when
      - active entities representing bfq_queues have differentiated weights,
        as in the original definition
      or (inclusive)
      - one or more entities representing groups of entities are active.
      
      This broader definition makes sure that I/O plugging will be performed
      in all the above cases, provided that there is at least one active
      group.  Of course, this definition is very coarse, so it will trigger
      I/O plugging also in cases where it is not needed, such as, e.g.,
      multiple active entities with just one child each, and all with the same
      I/O-request size.  The reason for this coarse definition is just that a
      finer-grained definition would be rather heavy to compute.
      
      On the opposite end, even this new definition does not trigger I/O
      plugging in all cases where there is no active group, and all bfq_queues
      have the same weight.  So, in these cases some unfairness may occur if
      there are asymmetries in I/O-request sizes.  We made this choice because
      I/O plugging may lower throughput, and probably a user that has not
      created any group cares more about throughput than about perfect
      fairness.  At any rate, as for possible applications that may care about
      service guarantees, bfq already guarantees a high responsiveness and a
      low latency to soft real-time applications automatically.
      Signed-off-by: NFederico Motta <federico@willer.it>
      Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      2d29c9f8
  6. 12 10月, 2018 2 次提交
  7. 11 10月, 2018 2 次提交
    • B
      drivers/block: remove redundant 'default n' from Kconfig-s · 486c6fba
      Bartlomiej Zolnierkiewicz 提交于
      'default n' is the default value for any bool or tristate Kconfig
      setting so there is no need to write it explicitly.
      
      Also since commit f467c564 ("kconfig: only write '# CONFIG_FOO
      is not set' for visible symbols") the Kconfig behavior is the same
      regardless of 'default n' being present or not:
      
          ...
          One side effect of (and the main motivation for) this change is making
          the following two definitions behave exactly the same:
      
              config FOO
                      bool
      
              config FOO
                      bool
                      default n
      
          With this change, neither of these will generate a
          '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
          That might make it clearer to people that a bare 'default n' is
          redundant.
          ...
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      486c6fba
    • B
      block: remove redundant 'default n' from Kconfig-s · 1306ad4e
      Bartlomiej Zolnierkiewicz 提交于
      'default n' is the default value for any bool or tristate Kconfig
      setting so there is no need to write it explicitly.
      
      Also since commit f467c564 ("kconfig: only write '# CONFIG_FOO
      is not set' for visible symbols") the Kconfig behavior is the same
      regardless of 'default n' being present or not:
      
          ...
          One side effect of (and the main motivation for) this change is making
          the following two definitions behave exactly the same:
      
              config FOO
                      bool
      
              config FOO
                      bool
                      default n
      
          With this change, neither of these will generate a
          '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
          That might make it clearer to people that a bare 'default n' is
          redundant.
          ...
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      1306ad4e