On Thu, 20 Aug 2020 10:41:39 -0700
Andrei Vagin wrote:
> 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 bloc
On Mon, 10 Aug 2020 17:41:32 +0200
Greg KH wrote:
> On Tue, Aug 11, 2020 at 01:27:00AM +1000, Eugene Lubarsky wrote:
> > On Mon, 10 Aug 2020 17:04:53 +0200
> > Greg KH wrote:
> And have you benchmarked any of this? Try working with the common
> tools that want this information and see if it a
On Fri, Aug 14, 2020 at 01:01:00AM +1000, Eugene Lubarsky wrote:
> On Wed, 12 Aug 2020 00:51:35 -0700
> Andrei Vagin 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
On Wed, 12 Aug 2020 00:51:35 -0700
Andrei Vagin 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 f
On Wed, Aug 12, 2020 at 10:47:32PM -0600, David Ahern wrote:
> On 8/12/20 1:51 AM, Andrei Vagin wrote:
> >
> > I rebased the task_diag patches on top of v5.8:
> > https://github.com/avagin/linux-task-diag/tree/v5.8-task-diag
>
> Thanks for updating the patches.
>
> >
> > /proc/pid files have th
On 8/12/20 1:51 AM, Andrei Vagin wrote:
>
> I rebased the task_diag patches on top of v5.8:
> https://github.com/avagin/linux-task-diag/tree/v5.8-task-diag
Thanks for updating the patches.
>
> /proc/pid files have three major limitations:
> * Requires at least three syscalls per process per fil
On Tue, Aug 11, 2020 at 12:58:47AM +1000, Eugene Lubarsky wrote:
> This is an idea for substantially reducing the number of syscalls needed
> by monitoring tools whilst mostly re-using the existing API.
>
> The proposed files in this proof-of-concept patch set are:
>
> * /proc/all/stat
> A
On Tue, Aug 11, 2020 at 01:27:00AM +1000, Eugene Lubarsky wrote:
> On Mon, 10 Aug 2020 17:04:53 +0200
> Greg KH wrote:
> > How many syscalls does this save on?
> >
> > Perhaps you want my proposed readfile(2) syscall:
> >
> > https://lore.kernel.org/r/20200704140250.423345-1-gre...@linuxfoun
On Mon, 10 Aug 2020 17:04:53 +0200
Greg KH wrote:
> How many syscalls does this save on?
>
> Perhaps you want my proposed readfile(2) syscall:
>
> https://lore.kernel.org/r/20200704140250.423345-1-gre...@linuxfoundation.org
> to help out with things like this? :)
The proposed readfile so
On Tue, Aug 11, 2020 at 12:58:47AM +1000, Eugene Lubarsky wrote:
> This is an idea for substantially reducing the number of syscalls needed
> by monitoring tools whilst mostly re-using the existing API.
How many syscalls does this save on?
Perhaps you want my proposed readfile(2) syscall:
This is an idea for substantially reducing the number of syscalls needed
by monitoring tools whilst mostly re-using the existing API.
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
A stat line for each process in the existing format.
* /proc/all/statm
sta
11 matches
Mail list logo
