[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2FE3777F-4BE0-4F77-B563-3A16BE05B988@vmware.com>
Date: Thu, 1 Jun 2023 09:07:22 +0000
From: Ajay Kaher <akaher@...are.com>
To: Steven Rostedt <rostedt@...dmis.org>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"shuah@...nel.org" <shuah@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-trace-kernel@...r.kernel.org"
<linux-trace-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"chinglinyu@...gle.com" <chinglinyu@...gle.com>,
Nadav Amit <namit@...are.com>,
"srivatsa@...il.mit.edu" <srivatsa@...il.mit.edu>,
Alexey Makhalov <amakhalov@...are.com>,
Vasavi Sirnapalli <vsirnapalli@...are.com>,
Tapas Kundu <tkundu@...are.com>,
"er.ajay.kaher@...il.com" <er.ajay.kaher@...il.com>
Subject: Re: [PATCH v3 00/10] tracing: introducing eventfs
> On 01-Jun-2023, at 2:30 PM, 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.
>
> Tracing events took ~9MB, with this approach it took ~4.5MB
> for ~10K files/dir.
>
Steve, I have used nested rw-semaphore for eventfs locking (same as in cifs).
As per Amit Nadav, this has to be revisited/reviewed. Please have a look and
share your thoughts.
-Ajay
Powered by blists - more mailing lists