eugenelisstreams,
SVR 4 calls runqueues() before a context switch (sleep or schedule) and
before returning to user mode (return from system call). When running a
kernel thread, the purpose is to avoid a context switch to the STREAMS
scheduler kernel thread.
LiS has a few problems in this regard that I alluded to in a previous
note: its kernel threads run at SCHED_FIFO with a priority of 50. Calling
runqueues() before exiting a system call will not avoid the context
switch (because the context switch will occur anyway: a real-time thread
has been woken). But your latency will be better, which I suppose explains
your 25%. If you combine that with dropping back to SCHED_RR and nice -19
on the kernel threads, then you can avoid the context switch altogether.
I suppose the only problem might be that some semaphore gets held while
queue are being run. Perhaps Dave could comment why it was removed in
the first place. (Removing it caused other problems, the put procedure
of the module at the top of the module stack used to execute in user
context in 2.16.18, but it executes in STREAMS scheduler context in 2.18.)
On 2.4 you will need over 350% more improvement to come even close to
Linux Fast-STREAMS.
I now have pipes at 47% on 2.4 SMP and 81% on FC4. I have one test
scenario (asynchronous read/write, size 4096 bytes) where LfS pipes run
at 110% of Linux native pipes. I show an inter-module performance on
FC4 for LfS that is twice that of LiS.
--brian
On Tue, 06 Dec 2005, [EMAIL PROTECTED] wrote:
>
> Brian,
>
> > LiS 2.18, unlike 2.16 does not run the STREAMS scheduler on exit
> from system calls.
>
> What I noticed in 2.18th lis_setqsched(can_call) function is that
> the 'can_call' flag processing is completely gone from that function
> comparing with 2.16.18.
>
> To measure impact of that 'can_call' thing I unconditionally set it to
> 0 in 2.16.18,
> i.e. all queuerun() processing were done in LiS kernel threads, like
> in 2.18.0.
> Performance of my loopback tests became slower by 25%.
>
> Then in 2.18.0 I added the following couple of lines at the very
> beginning of lis_setqsched():
>
> if ((can_call) && !(in_interrupt()))
> {
> lis_run_queues(my_cpu) ;
> }
>
> And performance gained 25% on my loopback test.
>
> Q: Why can_call processing was removed and can we safely put it back?
>
> thanks,
> --
> Eugene
>
> _________________________________________________________________
>
> Try the New Netscape Mail Today!
> Virtually Spam-Free | More Storage | Import Your Contact List
> [1]http://mail.netscape.com
>
> References
>
> 1. http://mail.netscape.com/
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
[EMAIL PROTECTED] ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Linux-streams mailing list
[email protected]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
