[OpenAFS-devel] rx_Listener receiver thread

[Derrick Brashear]

------=_Part_27552_31562100.1201191470498
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Jan 24, 2008 7:13 AM, Rainer Toebbicke <rtb@pclella.cern.ch> wrote:

> Continuing on the subject of scaling...
>
> the next problem we run into is that a single fileserver thread runs
> 100% CPU flat, and its the rx_Listener.
>
> The first puzzle is that I thought the Listener could trade place with
> another thread which somehow does not happen.


that's the "hot thread" behavior. it should happen automatically. however,
the trading places is only "i'll go service this and someone else gets to
listen"


> Worse, though, we're not able to drive the box at 100% (CPU || network
> || disk) despite plenty of test streams, hence the suspicion that the
> single "packet receiver" thread is the next bottleneck.
>

quite possibly.

>
> Looks tempting to start two of those and see whether all goes up in
> smoke, but perhaps somebody's already got an idea what to watch out
> for (I haven't looked up for example whether recvmsg() is
> thread-safe). Also if the packet dispatching then requires some high
> level lock, it would not add much concurrency.
>

Tom Keiser possibly has a good idea of the issues you'll see as far as
needed locks to do this, as he examined it for the multithread free packet
queueing.

------=_Part_27552_31562100.1201191470498
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">On Jan 24, 2008 7:13 AM, Rainer Toebbicke &lt;<a href="mailto:rtb@pclella.cern.ch">rtb@pclella.cern.ch</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Continuing on the subject of scaling...<br><br>the next problem we run into is that a single fileserver thread runs<br>100% CPU flat, and its the rx_Listener.<br><br>The first puzzle is that I thought the Listener could trade place with
<br>another thread which somehow does not happen.</blockquote><div><br>that&#39;s the &quot;hot thread&quot; behavior. it should happen automatically. however, the trading places is only &quot;i&#39;ll go service this and someone else gets to listen&quot;
<br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Worse, though, we&#39;re not able to drive the box at 100% (CPU || network<br>
|| disk) despite plenty of test streams, hence the suspicion that the<br>single &quot;packet receiver&quot; thread is the next bottleneck.<br></blockquote><div><br>quite possibly. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Looks tempting to start two of those and see whether all goes up in<br>smoke, but perhaps somebody&#39;s already got an idea what to watch out<br>for (I haven&#39;t looked up for example whether recvmsg() is<br>thread-safe). Also if the packet dispatching then requires some high
<br>level lock, it would not add much concurrency.<br></blockquote><div><br>Tom Keiser possibly has a good idea of the issues you&#39;ll see as far as needed locks to do this, as he examined it for the multithread free packet queueing.
<br><br></div><br></div><br>

------=_Part_27552_31562100.1201191470498--