On Thu, Aug 6, 2009 at 5:32 PM, Mike Christie <micha...@cs.wisc.edu> wrote:
>
> On 08/06/2009 05:26 AM, Erez Zilber wrote:
>> On Wed, Aug 5, 2009 at 10:22 PM, Mike Christie<micha...@cs.wisc.edu> 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, but because we have not
>>>>> called queue_work the workqueue code will not let the thread run so we
>>>>> never get to flush the signal until we reconnect and send down a login
>>>>> pdu (the login pdu does a queue_work finally).
>>>>>
>>>> When you say "the xmit thread is running", I guess that you mean that
>>>> the xmit thread is busy with IO, right? Note that I said that this
>>> No. workqueue.c:worker_thread() is spinning. It is looping because there
>>> is a signal pending, but the iscsi work code which has the flush_signals
>>> is not getting run because there is no work queued.
>>>
>>> So you could add a
>>>
>>> if (signal_pending(current))
>>> flush_signals(current)
>>>
>>> to worker_thread() "for" loop and I think this will fix the problem.
>>>
>>
>> Looks like this solves the problem. I've added the following patch to
>> the centos 5.3 kernel (2.6.18-128.1.6.el5):
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 8594efb..e148ed8 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -253,6 +253,9 @@ static int worker_thread(void *__cwq)
>>
>> set_current_state(TASK_INTERRUPTIBLE);
>> while (!kthread_should_stop()) {
>> + if (signal_pending(current))
>> + flush_signals(current);
>> +
>> add_wait_queue(&cwq->more_work,&wait);
>> if (list_empty(&cwq->worklist))
>> schedule();
>>
>> I'm running with open-iscsi.git + 2 commits from linux-2.6-iscsi.git
>> (9c302cc45b70ecc4b606d65a445902381066061b&
>> 75be23dc40ba2f215779d5ba60fda9a762271bbe).
>>
>> Will you push it upstream& into the RHEL kernel?
>>
>
> I am not sure. I was thinking that switching from a workqueue to a
> thread is the right thing to do. The drawback is that the workqueue is
> nice when there are multiple sessions for a host like is done with
> bnx2i, cxgb3i and be_iscsi. I can just queue_work and pass the
> connection to send on. If I switch to a work_queue I have to add my own
> code to do that.
>
> I am going to post a patch like you did to linux-kernel and see what
> people say is best. If it goes in then I will port to RHEL.
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "open-iscsi" group.
> To post to this group, send email to open-iscsi@googlegroups.com
> To unsubscribe from this group, send email to
> open-iscsi+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/open-iscsi
> -~----------~----~----~----~------~----~------~--~---
>
>
Mike,
We had this discussion a long time ago. I don't remember what
eventually happened with it. Did you push the workqueue patch to the
kernel? What about the suspend-and-wake patch?
Thanks,
Erez
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
