[PATCH] megaraid: convert to work_struct

2012-12-13 Thread Xiaotian Feng
There's no need to use delayed work, convert to use work_struct and cancel_work_sync(). Requested-by: Tejun Heo Signed-off-by: Xiaotian Feng Cc: Neela Syam Kolli Cc: "James E.J. Bottomley" Cc: linux-scsi@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- drivers/scsi/megaraid/megaraid_sas.h

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Bart Van Assche
On 12/11/12 23:46, scame...@beardog.cce.hp.com wrote: I would be curious to see what kind of results you would get with scsi_debug with fake_rw=1. I am sort of suspecting that trying to put an "upper limit" on scsi LLD IOPS performance by seeing what scsi_debug will do with fake_rw=1 is not real

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Bart Van Assche
On 12/11/12 01:00, scame...@beardog.cce.hp.com wrote: The driver, like nvme, has a submit and reply queue per cpu. This is interesting. If my interpretation of the POSIX spec is correct then aio_write() allows to queue overlapping writes and all writes submitted by the same thread have to be

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread scameron
On Thu, Dec 13, 2012 at 04:22:33PM +0100, Bart Van Assche wrote: > On 12/11/12 01:00, scame...@beardog.cce.hp.com wrote: > >The driver, like nvme, has a submit and reply queue per cpu. > > This is interesting. If my interpretation of the POSIX spec is correct > then aio_write() allows to queue ov

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Bart Van Assche
On 12/13/12 18:25, scame...@beardog.cce.hp.com wrote: On Thu, Dec 13, 2012 at 04:22:33PM +0100, Bart Van Assche wrote: On 12/11/12 01:00, scame...@beardog.cce.hp.com wrote: The driver, like nvme, has a submit and reply queue per cpu. This is interesting. If my interpretation of the POSIX spec

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Christoph Hellwig
On Thu, Dec 13, 2012 at 05:47:14PM +0100, Bart Van Assche wrote: > From my experience with block and SCSI drivers option (1) doesn't > look attractive from a performance point of view. From what I have > seen performance with QD=1 is several times lower than performance > with QD > 1. But maybe I o

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread scameron
On Thu, Dec 13, 2012 at 12:40:27PM +0100, Bart Van Assche wrote: > On 12/11/12 23:46, scame...@beardog.cce.hp.com wrote: > >I would be curious to see what kind of results you would get with > >scsi_debug > >with fake_rw=1. I am sort of suspecting that trying to put an "upper > >limit" > >on scsi

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Bart Van Assche
On 12/13/12 19:03, scame...@beardog.cce.hp.com wrote: What are your system specs? A quad core Intel i5-2400 @ 3.10 GHz. taskset -c "$cpu" dd if="$device" of=/dev/null bs=4k iflag=direct Please use fio instead of dd for any serious performance measurements. dd doesn't even guarantee

Re: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread scameron
On Thu, Dec 13, 2012 at 05:47:14PM +0100, Bart Van Assche wrote: > On 12/13/12 18:25, scame...@beardog.cce.hp.com wrote: > >On Thu, Dec 13, 2012 at 04:22:33PM +0100, Bart Van Assche wrote: > >>On 12/11/12 01:00, scame...@beardog.cce.hp.com wrote: > >>>The driver, like nvme, has a submit and reply q

RE: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Jack Wang
On 12/13/12 18:25, scame...@beardog.cce.hp.com wrote: > On Thu, Dec 13, 2012 at 04:22:33PM +0100, Bart Van Assche wrote: >> On 12/11/12 01:00, scame...@beardog.cce.hp.com wrote: >>> The driver, like nvme, has a submit and reply queue per cpu. >> >> This is interesting. If my interpretation of the P

Re: [PATCH] [SCSI] gdth: Remove buggy ROM handling

2012-12-13 Thread Bjorn Helgaas
On Tue, Nov 6, 2012 at 3:04 PM, Bjorn Helgaas wrote: > The ROM address handling in gdth_init_pci() is useless and possibly > dangerous. This patch removes it. > > "pci_resource_start(pdev, 8)" is not well-defined. PCI resources 0-5 are > standard PCI BARs and 6 is the expansion ROM. Resource 8

Re: [Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.

2012-12-13 Thread Chen Gang
于 2012年12月10日 16:02, Chris Boot 写道: > On 10/12/12 02:39, Chen Gang wrote: >> Hello Chris Boot: >> >> need I send the relative patch ? > > Hi Chen, > > Sorry, life got in the way this weekend. I'll try to get the patch sent > out today. > Have you sent ? I am already in linux-scsi@vger.ke

RE: SCSI mid layer and high IOPS capable devices

2012-12-13 Thread Jack Wang
Steve, Thanks for share detail of your problem. Yes you ‘re right about test I talk. Now I know what you want to discuss on this thread. Jack Right, but if I understand you correctly, you're ganging up 24 device queues and measuring aggregate iops across them all.  That is, you have 24 SAS disk

Re: [Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.

2012-12-13 Thread Stefan Richter
On Dec 14 Chen Gang wrote: > 于 2012年12月10日 16:02, Chris Boot 写道: > > On 10/12/12 02:39, Chen Gang wrote: > >> Hello Chris Boot: > >> > >> need I send the relative patch ? > > > > Hi Chen, > > > > Sorry, life got in the way this weekend. I'll try to get the patch sent > > out today. > > > >

Re: [Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.

2012-12-13 Thread Chen Gang
于 2012年12月14日 14:57, Stefan Richter 写道: > On Dec 14 Chen Gang wrote: >> 于 2012年12月10日 16:02, Chris Boot 写道: >>> On 10/12/12 02:39, Chen Gang wrote: Hello Chris Boot: need I send the relative patch ? >>> >>> Hi Chen, >>> >>> Sorry, life got in the way this weekend. I'll try to get t