On Thu, Oct 03, 2002 at 03:27:49PM +0200, Manfred Spraul wrote:
> Hi Linus,
>
> pipe_write contains a wakeup storm, 2 writers that write into the same
> fifo can wake each other up, and spend 100% cpu time with wakeup/schedule,
> without making any progress.
>
> The patch below was part of -dj, and IIRC even of -ac, for a few months,
> but it's more a rewrite of pipe_read and _write.
>
> Could you merge it, or do you want a minimal fix?
>
> The only regression I'm aware of is that
>
> $ dd if=/dev/zero | grep not_there
This makes 2.4.19 + Con Kolivas patch behave very bad.
The system goes slow, freeze, than wakes up, freeze again, etc.
I did "cat /dev/zero | grep nothing".
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 124592 292056 60624 70488 0 1 27 19 7 2 5 1 2
0 0 0 124592 292048 60632 70488 0 0 0 12 132 141 0 0 100
0 0 0 124588 292048 60632 70488 0 0 0 0 126 109 0 0 100
0 0 0 124588 292048 60632 70488 0 0 0 0 126 108 0 0 100
0 0 0 124588 292048 60632 70488 0 0 0 0 127 102 0 0 100
0 0 0 124588 292048 60632 70488 0 0 0 0 130 122 1 0 99
0 0 0 124568 292004 60632 70488 28 0 28 0 151 1836 5 1 94
1 0 0 124552 292004 60632 70488 0 0 0 0 150 530 6 1 93
0 0 0 124552 292004 60632 70488 0 0 0 0 130 496 4 1 95
0 0 0 124552 292004 60632 70488 0 0 0 0 138 1935 4 3 93
0 0 0 124528 290956 60632 70488 0 0 0 0 250 3075 17 2 81
0 0 0 124528 290948 60640 70488 0 0 0 44 143 197 0 0 100
0 0 0 124516 290948 60640 70488 0 0 0 0 134 170 0 0 100
1 0 0 124516 290952 60644 70488 0 0 4 0 143 186 0 1 99
1 0 0 124516 290944 60644 70488 0 0 0 0 126 104 0 0 100
2 0 0 124516 208760 60644 70488 4 0 4 0 136 37577 39 45 17
2 0 0 124516 126544 60652 70488 0 0 0 12 123 16596 72 28 0
2 0 1 253164 4832 54036 70120 16 660 16 660 148 69994 0 100 0
1 1 2 439472 3264 53880 70120 0 20704 0 20696 398 978 0 28 72
0 1 1 438920 3656 53088 70120 0 19496 0 19496 450 722 0 5 95
0 1 1 438596 3716 53024 70120 0 19944 0 19944 442 134 0 7 93
0 1 2 438364 3712 53004 70132 0 19944 20 19944 507 252 0 5 95
1 1 3 438104 3784 52932 70132 0 19804 0 19804 442 171 0 1 99
0 2 1 437884 3804 52892 70132 8 17956 8 17956 452 219 0 5 95
0 2 1 437660 3736 52860 70132 100 18124 100 18124 435 205 0 1 99
0 2 1 437440 3168 52796 70132 4 20392 4 20392 493 542 0 5 95
0 2 2 437328 3144 52760 70168 0 19976 0 20180 602 341 1 1 98
10 0 6 143432 294816 52384 70168 8 128296 8 128436 2961 502 0 5 95
1 0 0 133448 307256 52320 70168 352 0 356 44 225 330 0 1 99
1 0 0 133372 307256 52320 70168 0 0 0 0 130 109 0 0 100
1 0 0 133296 307240 52336 70168 0 0 0 56 123 101 0 0 100
1 0 0 133244 307240 52336 70168 0 0 0 0 119 96 0 0 100
2 0 0 132952 307240 52336 70168 0 0 0 0 124 309 1 1 98
> will fail due to OOM, because grep does something like
>
> for(;;) {
> rlen = read(fd, buf, len);
> if (rlen == len) {
> len *= 2;
> buf = realloc(buf, len);
> }
> }
>
> if it operates on pipes, and due to the improved syscall merging, read
> will always return the maximum possible amount of data. But that's a grep
> bug, not a kernel problem.
>
> The diff is older, but applies to 2.5.40 without offsets.
doesn't apply to 2.4.19
-alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:43 EST