On Mon, 10 May 1999, David S. Miller wrote:
> Date: Mon, 10 May 1999 12:21:58 +0200 (CEST)
> From: Ingo Molnar <mingo@chiara.csoma.elte.hu>
>
> And this all is a rather stupid testcase with no RL significance
> IMO, designed to show alleged recalculation costs. Jonathan, WHERE
> is that 'MAJOR bottleneck'?
>
> Ok, then what I personally want is a firm quantification of where the
> scheduling cost is coming from in the web server benchmarks.
This is coming from the linear search through the runqueue for an appropriate
goodness.
Greg Lindal suggested this alternate solution for schedule selection:
while (p!= &init_task)
{
if (can_schedule())
{
int weight = goodness(p,prev,this_cpu);
if (weight>=0)
{c=weight, next=p; break;}
} p = p->next_run
}
It allows a process to be selected in O(1) time. It is not fair, but it is
quick.
Iprobe gives us the following data:
Before patch: O(runqueue len)
Begin End Sample Image Total
Address Address Name Count Pct Pct
------- ------- ---- ----- --- ---
0000000000000000-00000000000029FC /usr/bin/httpd 127463 18.5
00000001200419A0-000000012004339F ap_vformatter 15061 11.8 2.2
FFFFFC0000300000-00000000FFFFFFFF vmlinux 482385 70.1
FFFFFC00003103E0-FFFFFC000031045F entInt 7848 1.6 1.1
FFFFFC0000315E40-FFFFFC0000315F7F do_entInt 48487 10.1 7.0
FFFFFC0000327A40-FFFFFC0000327D7F schedule 124815 25.9 18.1
FFFFFC000033FAA0-FFFFFC000033FCDF kfree 7876 1.6 1.1
FFFFFC00003A9960-FFFFFC00003A9EBF ip_queue_xmit 8616 1.8 1.3
FFFFFC00003B9440-FFFFFC00003B983F tcp_v4_rcv 11131 2.3 1.6
FFFFFC0000441CA0-FFFFFC000044207F do_csum_partial 43112 8.9 6.3
_copy_from_user
After patch: O(1)
Begin End Sample Image Total
Address Address Name Count Pct Pct
------- ------- ---- ----- --- ---
0000000000000000-0000000120006F2F /usr/bin/httpd 124718 24.5
000000012000F500-000000012000F9BF ap_bwrite 5455 4.4 1.1
00000001200419A0-000000012004339F ap_vformatter 14705 11.8 2.9
0000020000590000-0000020000772FFF /lib/libc-2.0.7.so 73230 14.4
00000200005F4E20-00000200005F4F7F memcpy 6409 8.8 1.3
FFFFFC0000300000-00000000FFFFFFFF vmlinux 299958 59.0
FFFFFC00003103E0-FFFFFC000031045F entInt 5309 1.8 1.0
FFFFFC0000315E40-FFFFFC0000315F7F do_entInt 31072 10.4 6.1
FFFFFC0000327A40-FFFFFC0000327D7F schedule 6363 2.1 1.3
FFFFFC00003B9440-FFFFFC00003B983F tcp_v4_rcv 10052 3.4 2.0
FFFFFC00003DA900-FFFFFC00003DAFBF make_request 5823 1.9 1.1
FFFFFC0000441CA0-FFFFFC000044207F do_csum_partial 32257 10.8 6.3
_copy_from_user
FFFFFC0000442900-FFFFFC0000442AD3 __copy_user 12138 4.0 2.4
As Dean has already stated, apache uses flock/fcntl around accept to guarentee
that only one process is waiting in accept.
Does flock/fcntl wake up all of the processes that are waiting on the lock?
If so, has the thundering herd problem just been pushed into flock/fcntl
instead of accept?
>
> I'm willing to accept any well founded explanation, and this is where
> most of the concern has been coming from.
--Phil
Digital/Compaq: HPSD/Benchmark Performance Engineering
Phillip.Ezolt@compaq.com ezolt@perf.zko.dec.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/