On Monday 08 of August 2011 12:20:14 you wrote: > (..snip..) > Your worry and idea are ok, but this enhancement looks rather confusing. > > Users would misunderstand switching by the min_clean_segments_low_prio > threshold. > > We already have mc_cleaning_interval and mc_nsegments_per_clean which > are applied when the number of clean segments is LESS than > min_clean_segments. OTOH, the low_prio_xx parameters are applied when > the number of clean segments is LARGER than the > min_clean_segments_low_prio. The comparision should be inverted. agreed. > And, we already have min_clean_segments threashold. Why not just add > mc_nice and mc_ionice as below (rather than introduce the new > threthold) ? > > # Sheduing priority > # if clean segments < min_clean_segments. > mc_nice -5 > > # IO sheduing class and priority > # if clean segments < min_clean_segments. > mc_ionice realtime switching to faster free-space reclaimation already increases load on the computer. If this also switched cleanerd to higher priority at the same moment, the load increase could be sharp and unpleaseant. The idea was to have three levels of cleanerd operation, rather than two. 1) slow operation 2) fast operation -- when less than min_clean_segments is available 3) fast & aggressive (high nice and ionice priority) -- when there's even less free space available ...with the hope that the 3rd level would rarely ever be reached, because the 2nd level would suffice most of the time. Cheers, -- dexen deVries [[[↓][→]]] For example, if the first thing in the file is: <?kzy irefvba="1.0" rapbqvat="ebg13"?> an XML parser will recognize that the document is stored in the traditional ROT13 encoding. (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt )) -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
