On 02/03/2010 10:03 AM, Or Gerlitz wrote:
Mike Christie wrote:
Doh forgot about the original issue. Nice idea and patch. Looks ok to me.
lets see... I was kind of under the impression that the --original-- or major
issue here
It is. Your patch was a incremental change that removed the extra
On 02/03/2010 10:08 AM, Or Gerlitz wrote:
Mike Christie wrote:
So in the end the only lock we would have in the io path is the per task one
and what you were thinking the patch buy us? less cpu usage? more iops? did you
had some proof-of-concept testbed that yielded this under the patch?
Mo
Mike Christie wrote:
> So in the end the only lock we would have in the io path is the per task one
and what you were thinking the patch buy us? less cpu usage? more iops? did you
had some proof-of-concept testbed that yielded this under the patch?
Or.
--
You received this message because you a
Or Gerlitz wrote:
> I can't go over this max when applying my patch of lockless flow for
> queuecommand / passthrough
this is the patch I was using till today when I started to suspect it doesn't
yield any
or very little of IOPS over the rest of the patches.
---
drivers/infiniband/ulp/iser/i
Mike Christie wrote:
> Doh forgot about the original issue. Nice idea and patch. Looks ok to me.
lets see... I was kind of under the impression that the --original-- or major
issue here
is the session lock being held for two much time and introducing too much of a
contention
both between the co
On 02/03/2010 03:09 AM, Or Gerlitz wrote:
[PATCH RFC] remove some of the locking in iser scsi command response flow
currently iser recv completion flow takes the session lock twice.
optimize it to avoid the first one by letting iser_task_rdma_finalize()
be called only from the cleanup_task call
Mike Christie wrote:
>> - the kfifo_put call is safe since there's one consumer (xmit flow under
>>lock for passthrough, and xmit worker for non passthrough) and one
>>producer (response flow has single tasklet instance).
> I do do not know what you mean that there is one consumer. There
On 02/02/2010 06:46 AM, Or Gerlitz wrote:
optimize iser scsi command response processing flow to avoid taking extra
reference on the iscsi task and to use libiscsi lockless completion path.
This way there's no contention on the session lock between the scsi command
submission to the scsi command
