On 03/01/2010 05:38 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:51 PM, Mike Christie wrote:
On 02/03/2010 06:07 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christie
wrote:
On 02/03/2010 01:50 AM, Erez Zilber wrote:
It looks like I posted it at Red Hat and never got
On Wed, Feb 3, 2010 at 11:51 PM, Mike Christie wrote:
> On 02/03/2010 06:07 AM, Erez Zilber wrote:
>>
>> On Wed, Feb 3, 2010 at 11:30 AM, Mike Christie
>> wrote:
>>>
>>> On 02/03/2010 01:50 AM, Erez Zilber wrote:
>
> It looks like I posted it at Red Hat and never got a response, and I
>>>
On 02/03/2010 06:07 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christie wrote:
On 02/03/2010 01:50 AM, Erez Zilber wrote:
It looks like I posted it at Red Hat and never got a response, and I
probably then forgot about it and never asked upstream. Will send mail
upstream now.
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christie wrote:
> On 02/03/2010 01:50 AM, Erez Zilber wrote:
>>>
>>> It looks like I posted it at Red Hat and never got a response, and I
>>> probably then forgot about it and never asked upstream. Will send mail
>>> upstream now.
>>
>> Which list are you send
On 02/03/2010 01:50 AM, Erez Zilber wrote:
It looks like I posted it at Red Hat and never got a response, and I
probably then forgot about it and never asked upstream. Will send mail
upstream now.
Which list are you sending it to? I thought it was lkml, but didn't
find any discussion there.
> It looks like I posted it at Red Hat and never got a response, and I
> probably then forgot about it and never asked upstream. Will send mail
> upstream now.
Which list are you sending it to? I thought it was lkml, but didn't
find any discussion there.
Erez
--
You received this message becaus
On Tue, Feb 2, 2010 at 6:59 PM, Mike Christie wrote:
> On 02/02/2010 09:25 AM, Erez Zilber wrote:
>>
>> On Thu, Aug 6, 2009 at 5:32 PM, Mike Christie
>> wrote:
>>>
>>> On 08/06/2009 05:26 AM, Erez Zilber wrote:
On Wed, Aug 5, 2009 at 10:22 PM, Mike Christie
wrote:
>
> On 0
On 02/02/2010 09:25 AM, Erez Zilber wrote:
On Thu, Aug 6, 2009 at 5:32 PM, Mike Christie wrote:
On 08/06/2009 05:26 AM, Erez Zilber wrote:
On Wed, Aug 5, 2009 at 10:22 PM, Mike Christiewrote:
On 08/05/2009 12:34 PM, Erez Zilber wrote:
I found it. The problem is that we will send the sig
On Thu, Aug 6, 2009 at 5:32 PM, Mike Christie wrote:
>
> On 08/06/2009 05:26 AM, Erez Zilber wrote:
>> On Wed, Aug 5, 2009 at 10:22 PM, Mike Christie wrote:
>>> On 08/05/2009 12:34 PM, Erez Zilber wrote:
> I found it. The problem is that we will send the signal if the xmit
> thread is run
On 08/06/2009 05:26 AM, Erez Zilber wrote:
> On Wed, Aug 5, 2009 at 10:22 PM, Mike Christie wrote:
>> On 08/05/2009 12:34 PM, Erez Zilber wrote:
I found it. The problem is that we will send the signal if the xmit
thread is running or not. If it is not running the workqueue code will
>>>
On Wed, Aug 5, 2009 at 10:22 PM, Mike Christie wrote:
>
> On 08/05/2009 12:34 PM, Erez Zilber wrote:
>>> I found it. The problem is that we will send the signal if the xmit
>>> thread is running or not. If it is not running the workqueue code will
>>> keep getting woken up to handle the signal, bu
On 08/05/2009 12:34 PM, Erez Zilber wrote:
>> I found it. The problem is that we will send the signal if the xmit
>> thread is running or not. If it is not running the workqueue code will
>> keep getting woken up to handle the signal, but because we have not
>> called queue_work the workqueue code
On Wed, Aug 5, 2009 at 7:45 PM, Mike Christie wrote:
>
> On 08/05/2009 11:33 AM, Mike Christie wrote:
>> On 08/05/2009 11:26 AM, Mike Christie wrote:
>>> On 08/05/2009 11:01 AM, Erez Zilber wrote:
On Wed, Aug 5, 2009 at 6:19 PM, Mike Christie
wrote:
> On 08/04/2009 01:12 PM, Erez
On 08/05/2009 11:33 AM, Mike Christie wrote:
> On 08/05/2009 11:26 AM, Mike Christie wrote:
>> On 08/05/2009 11:01 AM, Erez Zilber wrote:
>>> On Wed, Aug 5, 2009 at 6:19 PM, Mike Christie
>>> wrote:
On 08/04/2009 01:12 PM, Erez Zilber wrote:
> On Tue, Aug 4, 2009 at 8:17 PM, Mike Chri
On 08/05/2009 11:26 AM, Mike Christie wrote:
> On 08/05/2009 11:01 AM, Erez Zilber wrote:
>> On Wed, Aug 5, 2009 at 6:19 PM, Mike Christie wrote:
>>> On 08/04/2009 01:12 PM, Erez Zilber wrote:
On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie
wrote:
> Erez Zilber wrote:
>> I'm
On 08/05/2009 11:01 AM, Erez Zilber wrote:
> On Wed, Aug 5, 2009 at 6:19 PM, Mike Christie wrote:
>> On 08/04/2009 01:12 PM, Erez Zilber wrote:
>>> On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie
>>> wrote:
Erez Zilber wrote:
> I'm running with open-iscsi.git HEAD + the check suspend b
On Wed, Aug 5, 2009 at 6:19 PM, Mike Christie wrote:
> On 08/04/2009 01:12 PM, Erez Zilber wrote:
>> On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie wrote:
>>> Erez Zilber wrote:
I'm running with open-iscsi.git HEAD + the check suspend bit patch +
the wake xmit on error patch. If I discon
On 08/04/2009 01:12 PM, Erez Zilber wrote:
> On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie wrote:
>> Erez Zilber wrote:
>>> I'm running with open-iscsi.git HEAD + the check suspend bit patch +
>>> the wake xmit on error patch. If I disconnect the cable on the
>>> initiator side (even while not run
On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie wrote:
>
> Erez Zilber wrote:
>>
>> I'm running with open-iscsi.git HEAD + the check suspend bit patch +
>> the wake xmit on error patch. If I disconnect the cable on the
>> initiator side (even while not running IO), I see that after sending
>> the si
Erez Zilber wrote:
>
> I'm running with open-iscsi.git HEAD + the check suspend bit patch +
> the wake xmit on error patch. If I disconnect the cable on the
> initiator side (even while not running IO), I see that after sending
> the signal, the iscsi_q_XX thread reaches 100% cpu. I ran it over
On Sat, Aug 1, 2009 at 6:34 AM, Mike Christie wrote:
> Mike Christie wrote:
>> On 07/31/2009 04:03 AM, Hannes Reinecke wrote:
>>> Mike Christie wrote:
tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
if a connection goes bad. This then delays session
recovery, because that code mus
Mike Christie wrote:
> On 07/31/2009 04:03 AM, Hannes Reinecke wrote:
>> Mike Christie wrote:
>>> tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
>>> if a connection goes bad. This then delays session
>>> recovery, because that code must wait for the xmit
>>> thread to flush. OTOH, if we did not
On 07/31/2009 04:03 AM, Hannes Reinecke wrote:
> Mike Christie wrote:
>> tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
>> if a connection goes bad. This then delays session
>> recovery, because that code must wait for the xmit
>> thread to flush. OTOH, if we did not wait at all
>> we are less
Mike Christie wrote:
> tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
> if a connection goes bad. This then delays session
> recovery, because that code must wait for the xmit
> thread to flush. OTOH, if we did not wait at all
> we are less efficient in the lock management
> because we must rea
tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
if a connection goes bad. This then delays session
recovery, because that code must wait for the xmit
thread to flush. OTOH, if we did not wait at all
we are less efficient in the lock management
because we must reacquire the session lock every
time
25 matches
Mail list logo
