[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1674407228-49109-9-git-send-email-akaher@vmware.com>
Date: Sun, 22 Jan 2023 22:37:08 +0530
From: Ajay Kaher <akaher@...are.com>
To: rostedt@...dmis.org, mhiramat@...nel.org
Cc: 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,
Ajay Kaher <akaher@...are.com>
Subject: [PATCH 0/8] tracing: introducing eventfs
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.
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