Interesting results. I appreciate the testing.
I also appreciate your introducing these ideas over a year ago. At the time I did not simply apply your patch for the same reason that I did not apply Matt's first attempt. The patch introduced Linux kernel-isms into the main line of the LiS code, and I want that code to be portable. Matt's second attempt satisfies the portability requirements.
-- Dave
At 02:46 AM 1/15/2004 Thursday, Brian F. G. Bidulock wrote:
Eugene,
I think you are probably testing the latency of the round robin scheduler rather than the performance of LiS. These are the numbers I get: Tests performed with two child processes on either end of a pipe, one writing in a poll loop, the other reading in a poll loop, pipemod pushed on writing end, stream heads set RDMSG, reports every second on 2.5GHz Pentium IV. During testing the processor pins at 100%.
2.16.18 w/ performance enabled ------------------------------
(1 byte messages) -------------------- 4 Msgs read: 102808, throughput: 102808 bytes/sec 5 Msgs sent: 102798, throughput: 102798 bytes/sec
(64 byte messages) -------------------- 4 Msgs read: 101106, throughput: 6470845 bytes/sec 5 Msgs sent: 101050, throughput: 6467251 bytes/sec
(4096 byte messages) -------------------- 4 Msgs read: 59313, throughput: 242949250 bytes/sec 5 Msgs sent: 59114, throughput: 242131962 bytes/sec
2.16.16 ------------------------------
(1 byte messages) -------------------- 4 Msgs read: 49330, throughput: 49330 bytes/sec 5 Msgs sent: 49330, throughput: 49330 bytes/sec
(64 byte messages) -------------------- 4 Msgs read: 66653, throughput: 4265841 bytes/sec 5 Msgs sent: 66794, throughput: 4274822 bytes/sec
(4096 byte messages) -------------------- 4 Msgs read: 41133, throughput: 168481729 bytes/sec 5 Msgs sent: 41133, throughput: 168481718 bytes/sec
So, at 1 byte, the performance improvement is about 100%, at 64 bytes (within a FASTBUF), it is about 50%, and even at 4096 bytes (non-cache allocation), the improvement is about 45%.
You should note that if latency had increased, that throughput could not have increased so much with the processor pinned. This is the expected value in hardware aligned memory caches: a 50% improvement in CPU cache performance. But the 100% improvement at 1 byte is really impressive. A further improvement would be to cache the stream-head structures as well for better performance across the user interface.
I provided this patch on October 1, 2002. I find it interesting that it took
over a year for others to see any value in it. Your welcome, but someone could
at least say thank you now.
--brian
On Tue, 13 Jan 2004, Eugene LiS User wrote:
> Hello, > > I have tested and compared my comm driver with both LiS 2.16.16 > and performance improved LiS 2.16.18. > > The results are sort of interesting. > the CPU utilization on .18 vs .16 is 15% vs 30% (which is good) > the average response time, though, increased almost 30% (which is bad). > > It looks almost like .18 waits something somewhere for a 30% longer time > than .16 and that results in lesser CPU usage since it is idleing while > waiting for that little something. > > I'm curious if other people see anything similar? > > -- > Eugene > > > __________________________________________________________________ > New! Unlimited Netscape Internet Service. > Only $9.95 a month -- Sign up today at http://isp.netscape.com/register > Act now to get a personalized email address! > > Netscape. Just the Net You Need. > _______________________________________________ > Linux-streams mailing list > [EMAIL PROTECTED] > http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
-- 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
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
