1. 02 5月, 2017 2 次提交
    • X
      tcmu: Add global data block pool support · b6df4b79
      Xiubo Li 提交于
      For each target there will be one ring, when the target number
      grows larger and larger, it could eventually runs out of the
      system memories.
      
      In this patch for each target ring, currently for the cmd area
      the size will be fixed to 8MB and for the data area the size
      will grow from 0 to max 256K * PAGE_SIZE(1G for 4K page size).
      
      For all the targets' data areas, they will get empty blocks
      from the "global data block pool", which has limited to 512K *
      PAGE_SIZE(2G for 4K page size) for now.
      
      When the "global data block pool" has been used up, then any
      target could wake up the unmap thread routine to shrink other
      targets' data area memories. And the unmap thread routine will
      always try to truncate the ring vma from the last using block
      offset.
      
      When user space has touched the data blocks out of tcmu_cmd
      iov[], the tcmu_page_fault() will try to return one zeroed blocks.
      
      Here we move the timeout's tcmu_handle_completions() into unmap
      thread routine, that's to say when the timeout fired, it will
      only do the tcmu_check_expired_cmd() and then wake up the unmap
      thread to do the completions() and then try to shrink its idle
      memories. Then the cmdr_lock could be a mutex and could simplify
      this patch because the unmap_mapping_range() or zap_* may go to
      sleep.
      Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
      Signed-off-by: NJianfei Hu <hujianfei@cmss.chinamobile.com>
      Acked-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      b6df4b79
    • X
      tcmu: Add dynamic growing data area feature support · 141685a3
      Xiubo Li 提交于
      Currently for the TCMU, the ring buffer size is fixed to 64K cmd
      area + 1M data area, and this will be bottlenecks for high iops.
      
      The struct tcmu_cmd_entry {} size is fixed about 112 bytes with
      iovec[N] & N <= 4, and the size of struct iovec is about 16 bytes.
      
      If N == 0, the ratio will be sizeof(cmd entry) : sizeof(datas) ==
      112Bytes : (N * 4096)Bytes = 28 : 0, no data area is need.
      
      If 0 < N <=4, the ratio will be sizeof(cmd entry) : sizeof(datas)
      == 112Bytes : (N * 4096)Bytes = 28 : (N * 1024), so the max will
      be 28 : 1024.
      
      If N > 4, the sizeof(cmd entry) will be [(N - 4) *16 + 112] bytes,
      and its corresponding data size will be [N * 4096], so the ratio
      of sizeof(cmd entry) : sizeof(datas) == [(N - 4) * 16 + 112)Bytes
      : (N * 4096)Bytes == 4/1024 - 12/(N * 1024), so the max is about
      4 : 1024.
      
      When N is bigger, the ratio will be smaller.
      
      As the initial patch, we will set the cmd area size to 2M, and
      the cmd area size to 32M. The TCMU will dynamically grows the data
      area from 0 to max 32M size as needed.
      
      The cmd area memory will be allocated through vmalloc(), and the
      data area's blocks will be allocated individually later when needed.
      
      The allocated data area block memory will be managed via radix tree.
      For now the bitmap still be the most efficient way to search and
      manage the block index, this could be update later.
      Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
      Signed-off-by: NJianfei Hu <hujianfei@cmss.chinamobile.com>
      Acked-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      141685a3
  2. 03 4月, 2017 1 次提交
  3. 30 3月, 2017 3 次提交
  4. 19 3月, 2017 5 次提交
  5. 25 2月, 2017 1 次提交
  6. 14 2月, 2017 1 次提交
  7. 15 12月, 2016 1 次提交
  8. 10 12月, 2016 2 次提交
    • B
      target/user: Add an #include directive · f5045724
      Bart Van Assche 提交于
      Since this driver uses kmap_atomic(), include the highmem header file.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Nicholas Bellinger <nab@linux-iscsi.org>
      Cc: Andy Grover <agrover@redhat.com>
      f5045724
    • B
      target/user: Fix a data type in tcmu_queue_cmd() · ecaf597b
      Bart Van Assche 提交于
      This patch avoids that sparse reports the following error messages:
      
      drivers/target/target_core_user.c:547:13: warning: incorrect type in assignment (different base types)
      drivers/target/target_core_user.c:547:13:    expected int [signed] ret
      drivers/target/target_core_user.c:547:13:    got restricted sense_reason_t
      drivers/target/target_core_user.c:548:20: warning: restricted sense_reason_t degrades to integer
      drivers/target/target_core_user.c:557:16: warning: incorrect type in return expression (different base types)
      drivers/target/target_core_user.c:557:16:    expected restricted sense_reason_t
      drivers/target/target_core_user.c:557:16:    got int [signed] ret
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      ecaf597b
  9. 28 10月, 2016 3 次提交
    • J
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg 提交于
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      
      This protects the data structure from accidental corruption.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56989f6d
    • J
      genetlink: statically initialize families · 489111e5
      Johannes Berg 提交于
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      489111e5
    • J
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg 提交于
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a07ea4d9
  10. 20 10月, 2016 3 次提交
  11. 11 3月, 2016 6 次提交
  12. 07 2月, 2016 1 次提交
    • A
      target/user: Fix cast from pointer to phys_addr_t · 0633e123
      Arnd Bergmann 提交于
      The uio_mem structure has a member that is a phys_addr_t, but can
      be a number of other types too. The target core driver attempts
      to assign a pointer from vmalloc() to it, by casting it to
      phys_addr_t, but that causes a warning when phys_addr_t is longer
      than a pointer:
      
      drivers/target/target_core_user.c: In function 'tcmu_configure_device':
      drivers/target/target_core_user.c:906:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
      
      This adds another cast to uintptr_t to shut up the warning.
      A nicer fix might be to have additional fields in uio_mem
      for the different purposes, so we can assign a pointer directly.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      0633e123
  13. 20 1月, 2016 1 次提交
  14. 08 1月, 2016 1 次提交
    • S
      target/user: Allow user to set block size before enabling device · 81ee28de
      Sheng Yang 提交于
      The capability of setting hw_block_size was added along with 9c1cd1b6
      "target/user: Only support full command pass-through", though default
      setting override the user specified value during the enabling of device,
      which called by target_configure_device() to set block_size matching
      hw_block_size, result in user not able to set different block size other
      than default 512.
      
      This patch would use existing hw_block_size value if already set, otherwise
      it would be set to default value(512).
      
      Update: Fix the coding style issue.
      
      (Drop unnecessary re-export of dev->dev_attrib.block_size - nab)
      Signed-off-by: NSheng Yang <sheng@yasker.org>
      Cc: Andy Grover <agrover@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      81ee28de
  15. 07 1月, 2016 1 次提交
  16. 29 11月, 2015 2 次提交
  17. 11 9月, 2015 3 次提交
  18. 23 6月, 2015 1 次提交
  19. 02 6月, 2015 1 次提交
    • B
      target: Minimize SCSI header #include directives · ba929992
      Bart Van Assche 提交于
      Only include SCSI initiator header files in target code that needs
      these header files, namely the SCSI pass-through code and the tcm_loop
      driver. Change SCSI_SENSE_BUFFERSIZE into TRANSPORT_SENSE_BUFFER in
      target code because the former is intended for initiator code and the
      latter for target code. With this patch the only initiator include
      directives in target code that remain are as follows:
      
      $ git grep -nHE 'include .scsi/(scsi.h|scsi_host.h|scsi_device.h|scsi_cmnd.h)' drivers/target drivers/infiniband/ulp/{isert,srpt} drivers/usb/gadget/legacy/tcm_*.[ch] drivers/{vhost,xen} include/{target,trace/events/target.h}
      drivers/target/loopback/tcm_loop.c:29:#include <scsi/scsi.h>
      drivers/target/loopback/tcm_loop.c:31:#include <scsi/scsi_host.h>
      drivers/target/loopback/tcm_loop.c:32:#include <scsi/scsi_device.h>
      drivers/target/loopback/tcm_loop.c:33:#include <scsi/scsi_cmnd.h>
      drivers/target/target_core_pscsi.c:39:#include <scsi/scsi_device.h>
      drivers/target/target_core_pscsi.c:40:#include <scsi/scsi_host.h>
      drivers/xen/xen-scsiback.c:52:#include <scsi/scsi_host.h> /* SG_ALL */
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      ba929992
  20. 01 6月, 2015 1 次提交
    • N
      target: Drop lun_sep_lock for se_lun->lun_se_dev RCU usage · 4cc987ea
      Nicholas Bellinger 提交于
      With se_port and t10_alua_tg_pt_gp_member being absored into se_lun,
      there is no need for an extra lock to protect se_lun->lun_se_dev
      assignment.
      
      This patch also converts backend drivers to use call_rcu() release
      to allow any se_device readers to complete.  The call_rcu() instead
      of kfree_rcu() is required here because se_device is embedded into
      the backend driver specific structure.
      
      Also, convert se_lun->lun_stats to use atomic_long_t within the
      target_complete_ok_work() completion callback, and add FIXME for
      transport_lookup_tmr_lun() with se_lun->lun_ref.
      
      Finally, update sbp_update_unit_directory() special case usage with
      proper rcu_dereference_raw() and configfs symlink comment.
      Reported-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Chris Boot <bootc@bootc.net>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      4cc987ea