Phil Auld discovered that running trace-cmd on a machine that has a lot of CPUS (160 in his case), the filtering logic fails because it adds a filter to all events to not trace the recorder tasks, and we overrun the buffer.

https://lore.kernel.org/lkml/20190412135333.GB6201@pauld.bos.csb/T/#u

Having 160 items to check is a lot regardless. This can be done better by changing what gets written into the sorting algorithm to make it filter on ranges and not only individual pids.

If we have tasks with pids 100, 101, 102, 103, 104, 105, 106, instead of adding a filter making sure that the pid doesn't match each one, change it to see if the pids are not in a range of 100 through 106.

e.g. instead of

 (common_pid!=100)&&(common_pid!=101)&&(common_pid!=102)&&(common_pid!=103)&&(common_pid!=104)&&(common_pid!=105)&&(common_pid!=106)

write

 (!((common_pid>=100)&&(common_pid<=106)))

It will make the parsing in the kernel faster too.