[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230328184743.7984463b@gandalf.local.home>
Date: Tue, 28 Mar 2023 18:47:43 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ajay Kaher <akaher@...are.com>
Cc: mhiramat@...nel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, chinglinyu@...gle.com,
namit@...are.com, srivatsab@...are.com, srivatsa@...il.mit.edu,
amakhalov@...are.com, vsirnapalli@...are.com, tkundu@...are.com,
er.ajay.kaher@...il.com
Subject: Re: [PATCH 0/8] tracing: introducing eventfs
On Sun, 22 Jan 2023 22:37:08 +0530
Ajay Kaher <akaher@...are.com> wrote:
> Events Tracing infrastructure contains lot of files, directories
> (internally in terms of inodes, dentries). And ends up by consuming
> memory in MBs. We can have multiple events of Events Tracing, which
> further requires more memory.
>
> Instead of creating inodes/dentries, eventfs could keep meta-data and
> skip the creation of inodes/dentries. As and when require, eventfs will
> create the inodes/dentries only for required files/directories.
> Also eventfs would delete the inodes/dentries once no more requires
> but preserve the meta data.
>
Hi Ajay,
Is there going to be any more work on this?
-- Steve
> Tracing events took ~9MB, with this approach it took ~4.5MB
> for ~10K files/dir.
>
> [PATCH 1/8]: Introducing struct tracefs_inode
> [PATCH 2/8]: Adding eventfs-dir-add functions
> [PATCH 3/8]: Adding eventfs-file-add function
> [PATCH 4/8]: Adding eventfs-file-directory-remove function
> [PATCH 5/8]: Adding functions to create-eventfs-files
> [PATCH 6/8]: Adding eventfs lookup, read, open functions
> [PATCH 7/8]: Creating tracefs_inode_cache
> [PATCH 8/8]: Moving tracing events to eventfs
Powered by blists - more mailing lists