On 03/01/2010 05:38 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:51 PM, Mike Christiemicha...@cs.wisc.edu wrote:
On 02/03/2010 06:07 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christiemicha...@cs.wisc.edu
wrote:
On 02/03/2010 01:50 AM, Erez Zilber wrote:
It looks
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.
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christie micha...@cs.wisc.edu 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
On 02/03/2010 06:07 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christiemicha...@cs.wisc.edu 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
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 Christiemicha...@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
On 02/02/2010 09:25 AM, Erez Zilber wrote:
On Thu, Aug 6, 2009 at 5:32 PM, Mike Christiemicha...@cs.wisc.edu wrote:
On 08/06/2009 05:26 AM, Erez Zilber wrote:
On Wed, Aug 5, 2009 at 10:22 PM, Mike Christiemicha...@cs.wisc.eduwrote:
On 08/05/2009 12:34 PM, Erez Zilber wrote:
I found it.
On Wed, Aug 5, 2009 at 10:22 PM, Mike Christiemicha...@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
On 08/04/2009 01:12 PM, Erez Zilber wrote:
On Tue, Aug 4, 2009 at 8:17 PM, Mike Christiemicha...@cs.wisc.edu 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
On 08/05/2009 11:01 AM, Erez Zilber wrote:
On Wed, Aug 5, 2009 at 6:19 PM, Mike Christiemicha...@cs.wisc.edu wrote:
On 08/04/2009 01:12 PM, Erez Zilber wrote:
On Tue, Aug 4, 2009 at 8:17 PM, Mike Christiemicha...@cs.wisc.edu
wrote:
Erez Zilber wrote:
I'm running with open-iscsi.git
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 Christiemicha...@cs.wisc.edu wrote:
On 08/04/2009 01:12 PM, Erez Zilber wrote:
On Tue, Aug 4, 2009 at 8:17 PM, Mike Christiemicha...@cs.wisc.edu
wrote:
Erez
On Wed, Aug 5, 2009 at 7:45 PM, Mike Christiemicha...@cs.wisc.edu 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 Christiemicha...@cs.wisc.edu
wrote:
On
On Sat, Aug 1, 2009 at 6:34 AM, Mike Christiemicha...@cs.wisc.edu 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
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 Tue, Aug 4, 2009 at 8:17 PM, Mike Christiemicha...@cs.wisc.edu 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
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 efficient
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 wait at all
16 matches
Mail list logo