> >> Kosaki's patch's goal is that kswap doesn't yield cpu if the zone doesn't meet its > >> min watermark to avoid failing atomic allocation. > >> But this patch could yield kswapd's time slice at any time. > >> Doesn't the patch break your goal in bb3ab59683? > > > > No. it don't break. > > > > Typically, kswapd periodically call shrink_page_list() and it call > > cond_resched() even if bb3ab59683 case. > > Hmm. If it is, bb3ab59683 is effective really? > > The bb3ab59683's goal is prevent CPU yield in case of free < min_watermark. > But shrink_page_list can yield cpu from kswapd at any time. > So I am not sure what is bb3ab59683's benefit. > Did you have any number about bb3ab59683's effectiveness? > (Of course, I know it's very hard. Just out of curiosity) > > As a matter of fact, when I saw this Larry's patch, I thought it would > be better to revert bb3ab59683. Then congestion_wait could yield CPU > to other process. > > What do you think about? No. The goal is not prevent CPU yield. The goal is avoid unnecessary _long_ sleep (i.e. congestion_wait(BLK_RW_ASYNC, HZ/10)). Anyway we can't refuse CPU yield on UP. it lead to hangup ;) What do you mean the number? If it mean how much reduce congestion_wait(), it was posted a lot of time. If it mean how much reduce page allocation failure bug report, I think it has been observable reduced since half years ago. If you have specific worried concern, can you please share it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>