On Fri, Aug 14, 2020 at 01:01:00AM +1000, Eugene Lubarsky wrote: > On Wed, 12 Aug 2020 00:51:35 -0700 > Andrei Vagin <avagin@xxxxxxxxx> wrote: > > > Maybe we need resurrect the task_diag series instead of inventing > > another less-effective interface... > > I would certainly welcome the resurrection of task_diag - it is clearly > more efficient than this /proc/all/ idea. It would be good to find out > if there's anything in particular that's currently blocking it. Unfotunatly, I don't have enough time to lead a process of pushing task_diag into the upstream. So if it is interesting for you, you can restart this process and I am ready to help as much as time will permit. I think the main blocking issue was a lack of interest from the wide audience to this. The slow proc is the problem just for a few users, but task_diag is a big subsystem that repeats functionality of another subsystem with all derived problems like code duplication. Another blocking issue is a new interface. There was no consensus on this. Initially, I suggested to use netlink sockets, but developers from non-network subsystem objected on this, so the transaction file interface was introduced. The main idea similar to netlink sockets is that we write a request and read a response. There were some security concerns but I think I fixed them. > > This RFC is mainly meant to check whether such an addition would > be acceptable from an API point of view. It currently has an obvious > performance issue in that seq_file seems to only return one page at a > time so lots of read syscalls are still required. However I may not > have the time to figure out a proposed fix for this by myself. > Regardless, text-based formats can't match the efficiency of task_diag, > but binary ones are also possible. I don't have objections to this series. It can be an option if we will decide that we don't want to do a major rework here. Thanks, Andrei
