|
»
»
howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
 |
howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by Kacper Wysocki
::
Rate this Message:
On 7/25/07, Ingo Molnar <mingo@...> wrote:
> > * Rene Herman <rene.herman@...> wrote: > > > Nick Piggin is the person to convince it seems and if I've read things > > right (I only stepped into this thing at the updatedb mention, so > > maybe I haven't) his main question is _why_ the hell it helps > > updatedb. [...] [snip howto get a patch merged] > But a "here is a solution, take it or leave it" approach, before having > communicated the problem to the maintainer and before having debugged > the problem is the wrong way around. It might still work out fine if the > solution is correct (especially if the patch is small and obvious), but > if there are any non-trivial tradeoffs involved, or if nontrivial amount > of code is involved, you might see your patch at the end of a really > long (and constantly growing) waiting list of patches. Is that what happened with swap prefetch these two years? The approach has been wrong? In this particular instance, there are lots of people who have looked at, tried, tested, reported on, advocated, and most importantly -been using for several years- swap prefetch. That's a lot of people, it's hard to coordinate a unified approach, eh? You are the gatekeepers. The dudes with the keys. The guys who must claim technical and moral superiority over the rabble, the rest of us. I always believed that the linux development model consisted of collaboration with technical merit as the prime goal in mind. But the sheer volume of patches and the small number of keyholders precludes such a scenario. So the gatekeepers have trusted advisors, and it's quicker to look at numbers than to try out all the random (and often crappy) patches that flow in. It's easier to ask for more testing, more feedback, more "unbiased", easier to just drop it rather than to look at the new code itself. It's easier and less risky to try and understand a problem yourself, and write your own code. After all, you trust your own code, right? Life is so much simpler without any alien objects around. However, cool things usually come from outside such a stable environment. The problem isn't debugging the wrong way around. The problem is no matter how many people read it, test it, use it, brag about it, measure it, it doesn't matter at all unless they can convince one of these few dudes that he should really turn that key. 0K _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
Re: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by Rene Herman-2
::
Rate this Message:
On 07/25/2007 05:30 PM, Kacper Wysocki wrote:
>>> main question is _why_ the hell it helps updatedb. > Is that what [ ... ] And there we go again -- off into blabber-land. Why does swap-prefetch help updatedb? Or doesn't it? And if it doesn't, why should anyone trust anything else someone who said it does says? Rene. _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
Re: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by Ingo Molnar
::
Rate this Message:
* Kacper Wysocki <kacperw@...> wrote: > [snip howto get a patch merged] > > But a "here is a solution, take it or leave it" approach, before > > having communicated the problem to the maintainer and before having > > debugged the problem is the wrong way around. It might still work > > out fine if the solution is correct (especially if the patch is > > small and obvious), but if there are any non-trivial tradeoffs > > involved, or if nontrivial amount of code is involved, you might see > > your patch at the end of a really long (and constantly growing) > > waiting list of patches. > > Is that what happened with swap prefetch these two years? The approach > has been wrong? i dont know - but one of the maintainers of the code (Nick) says that he asked for but did not get debug feedback: > > > And yet despite my repeated pleas, none of those people has yet > > > spent a bit of time with me to help analyse what is happening. Con, the maintainer of -ck, certainly has (or had, when he maintained it) enough clout to coordinate such an effort between non-developer -ck users and the MM maintainers. Maybe he attempted to do that and has tried to provide debug feedback to MM maintainers? Ingo _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
Re: Re: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by michael chang
::
Rate this Message:
On 7/25/07, Ingo Molnar <mingo@...> wrote:
> > * Kacper Wysocki <kacperw@...> wrote: > > > [snip howto get a patch merged] > > > > But a "here is a solution, take it or leave it" approach, before > > > having communicated the problem to the maintainer and before having > > > debugged the problem is the wrong way around. It might still work > > > out fine if the solution is correct (especially if the patch is > > > small and obvious), but if there are any non-trivial tradeoffs > > > involved, or if nontrivial amount of code is involved, you might see > > > your patch at the end of a really long (and constantly growing) > > > waiting list of patches. > > > > Is that what happened with swap prefetch these two years? The approach > > has been wrong? > > i dont know - but one of the maintainers of the code (Nick) says that he > asked for but did not get debug feedback: Perhaps this is unimportant now, I don't know, but who did he ask? Where did he ask? Where should the feedback have gone? (For example, is he subscribed to -ck?) To be perfectly honest, I find this very surprising, considering the number of people that appear to be supporting this patch. I can only wonder whether it's possible this request never got to any of them. -- Michael Chang Please avoid sending me Word or PowerPoint attachments. Send me ODT, RTF, or HTML instead. See http://www.gnu.org/philosophy/no-word-attachments.html Thank you. _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
Re: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by Robert Deaton
::
Rate this Message:
On 7/25/07, Rene Herman <rene.herman@...> wrote:
> And there we go again -- off into blabber-land. Why does swap-prefetch help > updatedb? Or doesn't it? And if it doesn't, why should anyone trust anything > else someone who said it does says? I don't think anyone has ever argued that swap-prefetch directly helps the performance of updatedb in any way, however, I do recall people mentioning that updatedb, being a ram intensive task, will often cause things to be swapped out while it runs on say a nightly cronjob. If a person is not at their computer, updatedb will run, cause all their applications to be swapped out, finish its work, and exit, leaving all the other applications that would have otherwise been left in RAM for when the user returns to his/her computer in swap. Thus, when someone returns, you have to wait for all your applications to be swapped back in. Swap prefetch, on the other hand, would have kicked in shortly after updatedb finished, leaving the applications in swap for a speedy recovery when the person comes back to their computer. -- --Robert Deaton _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
|
|
|
|
|
|
Re: updatedb
by Björn Steinbrink
::
Rate this Message:
On 2007.07.26 11:58:29 +0200, Björn Steinbrink wrote:
> Note that the total RSS usage of updatedb+sort was just about 50MB, > nevertheless swap grew to more than 300MB. It's also interesting that > swapping is so aggressive, that the amount of free memory is constantly > growing. I'm a missing something or wouldn't it be smarter to use that > free memory for buffers and cache first? (x86_64 system, so even if > highmem on x86 could be responsible, it's not the case here.) > > Will now go and see what happens if I play with swappiness. Hm, swappiness set to 0 looks even more weird to me, especially the beginning, where (AFAICT) basically buffers and caches are dropped just to get a pretty huge amount of free RAM. With swappiness set to 100, you basically get what you expect: swapping. But at least to me, that swapping looks _a lot_ smarter than what it did for the default swappiness of 60 or the 0 swappiness. Swap is growing, but so are the buffers, and the cache also only shrinks at a single point, probably when the "sort" process starts to grow. Plus, the amount of free memory isn't growing to insane sizes like in the other cases. vmstat output for both cases to be found below. Björn vmstat output for swappiness = 0 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 25140 37712 65304 1 1 7 14 4 31 0 0 99 0 4 0 0 25132 37736 65312 0 0 0 38 212 604 1 0 98 1 2 0 0 25132 37736 65312 0 0 0 0 177 479 0 0 100 0 3 1 0 17252 42568 65312 0 0 1516 23 641 2332 1 3 54 41 3 2 0 15172 45412 59908 0 0 1567 482 585 2051 1 4 50 45 2 2 0 20436 44320 54524 0 0 743 9 368 1196 0 1 50 49 3 2 0 28416 36580 54520 0 0 533 4 312 1016 0 1 50 49 1 2 4 44316 22780 54464 0 0 128 191 240 786 1 1 43 54 3 0 3884 55256 18112 45772 0 0 356 277 318 937 0 3 39 57 1 2 3924 57276 19004 40700 0 0 631 117 347 1160 0 1 50 48 0 1 4108 61328 15348 40344 0 0 768 301 378 1218 0 1 50 49 1 1 4276 60812 15612 40216 0 300 585 359 344 1045 0 1 50 49 0 2 4276 62184 17484 39624 0 995 703 1208 370 1188 0 2 50 48 0 2 4296 68244 14616 36268 0 0 360 11 275 973 0 1 50 49 2 2 4296 75292 6976 36016 0 137 667 480 424 1315 0 3 50 47 3 1 4300 78984 6344 33392 0 0 639 635 517 1142 0 3 49 47 2 1 4300 80816 5520 32520 0 1 992 587 683 1479 0 7 48 45 1 2 4556 82244 3704 32504 0 85 607 659 452 1040 0 3 50 47 0 1 4556 81600 4972 32420 0 0 665 44 362 1040 0 1 50 49 0 2 4940 80364 4588 32508 0 128 552 539 375 995 0 3 50 47 0 1 5004 83116 3576 32420 0 21 416 591 405 862 0 3 49 47 0 1 5004 80196 5388 32440 0 0 604 0 328 1014 0 2 50 48 0 1 5004 82976 2548 32544 0 0 461 343 363 923 0 4 49 47 1 1 5004 81528 3780 32472 0 0 1124 157 542 1524 1 4 49 47 0 1 5516 81940 4000 32488 0 171 865 575 489 1356 0 4 49 46 0 2 5804 82412 2380 32516 0 96 660 423 385 1160 1 6 42 51 0 2 5804 81476 2868 32480 0 0 864 204 493 1242 0 5 50 45 0 1 6268 83124 2088 32508 0 155 678 551 409 1107 0 7 46 47 0 2 6268 83216 1576 32380 0 0 771 153 450 1330 1 11 43 46 0 3 59420 97888 736 32224 0 17717 300 18035 375 869 0 27 12 60 0 4 176160 214288 800 32316 0 38913 23 38917 347 502 0 6 30 64 1 2 176212 242608 2752 32716 0 17 683 95 441 1256 0 4 41 54 1 1 176212 237464 5492 32568 0 0 883 188 452 1488 1 2 50 48 1 0 176212 232296 9628 32636 0 0 1368 263 533 1690 1 2 50 47 0 1 176212 225852 13264 32652 0 0 1212 0 480 1818 1 3 50 46 0 1 176212 202076 31708 32660 0 0 6143 348 1723 5654 2 7 50 41 0 1 176212 177196 49952 32560 0 0 6081 0 1698 5413 1 6 50 43 0 1 176212 147744 58332 32652 0 0 2791 467 884 3565 1 5 50 44 0 1 176212 130604 63788 32664 0 0 1813 407 645 2637 1 5 50 44 0 1 176212 119076 68012 32584 0 0 1408 0 529 2239 0 4 50 45 2 1 176212 74112 83696 32600 0 0 5225 667 1496 7206 5 13 50 33 1 1 176212 29296 99788 32620 0 0 5360 16 1524 7009 4 15 49 32 0 1 176212 16012 105112 32660 0 0 1773 2901 891 2417 1 4 50 45 1 1 194444 16656 117236 32624 0 6077 4036 6337 1228 6040 6 9 49 36 1 1 194572 15996 122056 32568 0 43 1607 43 579 2740 1 5 50 44 0 1 209788 15888 125520 32636 0 5072 1149 5520 503 1836 1 4 49 46 0 1 231568 17304 133968 32884 21 7260 2933 7260 922 3912 2 9 46 43 0 1 231568 16300 139004 32980 0 0 1695 523 636 2077 1 3 49 46 1 1 238440 15900 145208 33072 0 2291 2102 2722 736 2482 1 5 49 46 2 0 246140 15940 147788 32980 0 2545 860 2545 407 1353 21 3 39 36 4 0 246140 16712 147680 32980 0 0 0 247 190 544 50 0 50 0 3 0 246140 15392 147680 32980 0 0 0 0 177 508 50 1 49 0 3 0 277644 18180 147688 32980 0 10501 0 10511 229 518 50 0 47 2 4 0 277644 15940 147688 32980 0 0 0 1747 361 514 50 0 49 1 4 0 277644 16880 147700 33212 0 0 79 15 221 519 49 0 50 1 0 2 309192 13900 147560 61856 0 10516 11 10523 186 528 46 3 49 2 4 0 315176 70264 149128 62880 0 1995 411 11668 506 2372 5 3 38 53 0 0 315176 95912 149212 38104 0 0 132 68 197 16128 23 6 69 2 0 0 315176 95920 149232 38104 0 0 0 1568 216 488 0 0 98 1 0 0 315176 95920 149240 38104 0 0 0 9 201 662 0 1 99 0 ------------------------ vmstat output for swappiness = 100 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 17120 150356 45104 1 1 8 14 4 32 0 0 99 0 1 0 0 17072 150360 45160 0 0 1 0 190 700 0 0 100 0 0 0 0 17072 150380 45160 0 0 0 44 196 610 0 1 98 1 0 1 6944 15320 154124 45304 0 2315 1211 2315 582 2141 0 4 54 41 3 1 17752 16780 159000 45164 0 3603 1614 4039 618 2062 0 2 48 50 2 1 17876 15700 163044 45228 0 41 1348 41 514 2013 0 2 50 48 3 1 32372 16872 166124 45180 0 4832 1021 5104 491 1888 1 4 50 45 0 1 39964 16640 168620 45184 0 2531 844 2564 427 1331 0 4 50 46 0 1 39964 15868 170580 45216 0 0 651 331 351 1096 0 1 50 49 0 1 47312 16164 172184 45240 0 2449 529 2653 336 915 0 1 50 49 3 1 55180 15392 174656 45140 0 2623 825 2623 397 1212 1 1 50 48 0 1 63256 15648 177380 45168 0 2692 904 3085 433 1527 1 4 50 45 2 1 68672 15408 180608 45136 0 1805 1076 2199 516 1506 0 3 50 47 2 1 73804 16628 182420 45156 0 1711 599 2144 352 1066 1 1 50 48 2 1 77396 16412 184192 45152 0 1197 588 1559 337 1066 0 0 50 50 2 1 79668 16492 185944 45112 0 757 581 773 334 1058 0 2 50 48 3 1 88964 15588 187452 45092 0 3099 500 3480 331 1046 0 1 49 50 2 1 89040 16700 188940 45072 0 25 495 55 313 1135 0 1 50 49 4 1 97700 15716 192584 45108 0 2887 1212 3197 503 1706 0 3 49 48 3 1 99952 15564 195144 45056 0 751 851 2420 650 1289 0 3 50 47 2 1 108624 15988 198256 45084 0 2891 1035 3045 455 1449 0 2 50 48 2 1 117380 16664 200972 45080 0 2919 911 3257 430 1368 1 3 50 46 3 1 175564 44768 180728 43316 11 19383 321 19412 370 2982 4 22 43 31 5 0 175664 53424 160468 43048 11 33 1617 189 586 2834 1 8 50 41 2 1 175744 54132 153648 42920 0 27 1163 1571 495 2032 1 6 49 44 2 1 176116 41212 144836 32460 0 103 5997 756 1692 8567 7 18 49 27 4 0 197192 40988 150000 19180 11 5592 3716 5592 1133 5697 3 9 47 41 2 1 212884 45396 156332 19144 11 5231 2119 5573 746 2952 0 5 49 46 3 1 226452 25416 166504 19132 0 4523 4388 4527 1301 6233 4 14 49 33 3 1 233632 26628 168816 19188 11 2393 779 2676 394 1376 0 2 50 48 2 1 242304 25748 171292 19192 21 2891 1189 3339 496 1856 1 4 50 45 3 0 259492 24100 176708 19192 0 5729 1871 5739 678 2703 1 5 50 44 1 1 259512 16628 184492 18864 0 7 2591 1047 969 3416 1 7 50 42 2 1 270404 16984 190096 18920 11 3631 2035 3643 712 2367 1 4 50 45 2 1 276056 17440 191416 18860 43 1884 656 4713 575 1212 0 2 50 48 3 0 280704 16040 192140 18932 0 1549 439 1561 301 950 41 1 38 20 4 0 280704 16200 192124 18932 21 0 21 1384 348 531 50 0 49 0 3 0 280704 16352 192132 18932 11 0 11 9 183 524 50 0 50 0 3 0 280704 15396 192132 18932 11 0 11 0 180 519 50 0 50 0 3 0 286300 15740 191632 18932 11 1865 11 1877 194 529 49 0 50 1 3 0 286300 16216 191644 19032 85 0 128 0 183 539 50 0 49 1 3 0 324104 15824 191784 48024 21 12601 108 15856 299 678 22 4 45 29 4 0 323904 62648 193092 51844 11 0 375 28 347 16416 26 6 43 25 2 0 323904 92140 193156 23880 11 0 82 1609 220 1439 1 2 95 3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@... More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
Re: Re: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)
by jos poortvliet
::
Rate this Message:
On 7/25/07, Robert Deaton <false.hopes@...> wrote:
On 7/25/07, Rene Herman <rene.herman@...> wrote: Note that the updatedb scenario should actually be properly fixed some other way: updatedb, touching everything only once, shouldn't dirty the caches like it does. But the same thing happens when you open a 10 megapixel picture for editing in Krita, or start OpenOffice. After closing them, a lot of ram is freed. Yet the data which is pushed to swap when you used these apps will remain there, until you start using them. Swap-prefetch will gently get this data back (while keeping it also in swap, to ensure a quick response when the ram is needed for another big app - so you have the advantages, but not the disadvantages!). I haven't heard anyone claim this scenario can be 'fixed' in a 'more proper' way than with swap prefetch. And nobody has been able to prove that swap-prefetch has any bad sideeffects. So it IS a net-gain. But only for desktop users who hit swap. So it's good for those doing video and photo editing, for example. Or low-mem systems with OpenOffice. Or ppl doing heavy compiles while low on ram. It doesn't help nor hinder laptop users (it is automatically turned off on laptops to save power), and it doesn't help nor hinder big 16-gb-ram systems (they probably don't hit swap often, quick responses might not be important, they're mostly busy so swap-prefetch doesn't run and most importantly: they won't have it turned on anyway). -- _______________________________________________ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: ck@... http://vds.kolivas.org/mailman/listinfo/ck |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
