On 2024-02-27 19:17:48 [+0200], Lasse Collin wrote: > Thanks for the patch! We discussed a bit on IRC and everyone thinks > it's on the right track but we are pondering the implementation details > still. > > The thread count messages are shown in situations which don't affect > the compressed output, and thus the importance of these messages isn't > so high. Originally they were there to reduce the chance of people > asking why xz isn't using as many threads as requested.
Understood. > We are considering to simply change those two message() calls to always > use V_VERBOSE or V_DEBUG instead of the current V_WARNING. So automatic > vs. manual number of threads wouldn't affect it like it does in your > patch. Comparing your apporach and this simpler one: > > + There are scripts that take a user-specified number for > parallelization and that number is passed to multiple tools, not > just xz. Keeping xz -T16 silent about thread count reduction can > make sense in this case. > > - The silencing could be done with -q as well though. Wouldn't -q also shut some legitime warnings? > There are pros and cons between V_VERBOSE and V_DEBUG. > > For (de)compression, a single -v sets V_VERBOSE and actives the > progress indicator. If the thread count messages are shown at -v, on > some systems progress indicator usage would get the message about > reduced thread count as well. > > + It works as a hint that increasing the memory usage limits manually > might allow more threads to be used. > > - If one uses progress indicator frequently, the thread count > reduction message might become slightly annoying as the information > is already known by the user. > > - Progress indicator can be used in non-interactive cases (when > stderr isn't a terminal). Then xz only prints a final summary per > file. This likely is not a common use case but the thread count > messages would be here as well. > > V_DEBUG is set when -v is used twice (-vv). > > + Regular progress indicator uses wouldn't get extra messages. > > - A larger number of users might not become aware that they aren't > getting as many threads as they could because the automatic memory > usage limit is too low to allow more threads. Isn't the automatic memory usage accurate? Because then there is hardly something you could do about it. Maybe kill chrome… On the other hand if they decompress and they have 32s CPU and xz reduces it to 16 threads then there is no "loss" if the file has 16 blocks or less :) Not sure if documenting it in the man-page would help here. > There are also messages that are shown when memory limit does affect > compressed output (switching to single-threaded mode and LZMA2 > dictionary size adjustment). The verbosity requirement of these messages > isn't being changed now. This sounds like you accept this change in principle but are thinking if V_VERBOSE or V_DEBUG is the right thing. Sebastian
