Re: LiS-2.18 performance ?

LiS does not wake up additional queue run threads until there are 
around a dozen queues to process in the list.  It is not deemed to be 
worth the task wakeup time for lesser amounts.  I did some 
performance testing and found that list lengths in that range were 
about optimal.

You can't do put/service processing from interrupt level because of 
having to "down" semaphores, which operation can only be performed 
from process level.

I am sure that Brian's Fast STREAMS has a far superior solution to 
these problems.

-- Dave

At 08:13 AM 12/2/2005, [email protected] wrote:
>Hello,
>
>I'm curious about people impressions about LiS-2.18 performance.
>Is it better comparing to LiS-2.16.18 ?
>
>Are there any known 2.18 issues that can be fixed to improve performance?
>
>My understanding is that in LiS-2.18 most(all?) of the queue processing
>is done by LiS kernel threads and queuerun is never executed from
>the driver tasklet context.  That may result, I guess, in excessive process
>switching overhead and poorer performance.
>I might be missing something, though.
>
>The other thing I noticed when I ran my tests on a 4 processor system
>is that only one LiS thread accumulated CPU time:
>
>root 9574 1 0 Dec01 ? 00:02:27 [LiS-2.18.0:0]  <-------
>root 9575 1 0 Dec01 ? 00:00:01 [LiS-2.18.0:1]
>root 9576 1 0 Dec01 ? 00:00:00 [LiS-2.18.0:2]
>root 9577 1 0 Dec01 ? 00:00:00 [LiS-2.18.0:3]
>
>Is it the way it's supposed to be, or  it's a bug?
>
>
>I'd appreciate any comment/advices regarding performance issues on LiS-2.18.
>
>--
>Eugene
>
>
>
>
>
>----------
>Try the New Netscape Mail Today!
>Virtually Spam-Free | More Storage | Import Your Contact List
><http://mail.netscape.com>http://mail.netscape.com