Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 04/16] rv/include: Add deterministic automata monitor
 definition via C macros
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
        Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>,
        Kate Carcia <kcarcia@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Ingo Molnar <mingo@redhat.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Joel Fernandes <joel@joelfernandes.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Gabriele Paoloni <gabriele.paoloni@intel.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Clark Williams <williams@redhat.com>, linux-doc@vger.kernel.org
References: <cover.1621414942.git.bristot@redhat.com>
 <1e67370a0808714325b434edfe8f84178867af47.1621414942.git.bristot@redhat.com>
 <20210519182739.GG21560@worktop.programming.kicks-ass.net>
From:   Daniel Bristot de Oliveira <bristot@redhat.com>
Message-ID: <c638d724-c9d8-d640-eb99-8e684e2d594b@redhat.com>
Date:   Thu, 20 May 2021 09:13:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <20210519182739.GG21560@worktop.programming.kicks-ass.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/19/21 8:27 PM, Peter Zijlstra wrote:
> On Wed, May 19, 2021 at 01:36:25PM +0200, Daniel Bristot de Oliveira wrote:
> 
>> +struct da_monitor {
>> +	char curr_state;
>> +	bool monitoring;
>> +	void *model;
>> +};
>> +
>> +#define MAX_PID		 1024000
> 
>> +/*
>> + * Functions to define, init and get a per-task monitor.
>> + *
>> + * XXX: Make it dynamic? make it part of the task structure?
> 
> Yes !
> 
> I'd start with maybe adding a list_head to da_monitor and embedding a
> single copy into task_struct and link from there. Yes lists suck, but
> how many monitors do you realistically expect to run concurrently?

Good to know I can use the task struct! This will make my life easier. I did it
this way because I started doing the code all "out-of-tree," as modules... but
being in kernel gives such possibilities.

I will try to implement your idea! I do not see many concurrent monitors
running, and as the list search will be linear to the number of active
monitors... it might not even justify any more complex data structure.

Thanks Peter!

-- Daniel

>> + */
>> +#define DECLARE_DA_MON_INIT_PER_TASK(name, type)				\
>> +										\
>> +struct da_monitor da_mon_##name[MAX_PID];					\
> 
> That's ~16M of memory, which seems somewhat silly.
> 
>> +										\
>> +static inline struct da_monitor *da_get_monitor_##name(pid_t pid)		\
>> +{										\
>> +	return &da_mon_##name[pid];						\
>> +}										\
>> +										\
>> +void da_monitor_reset_all_##name(void)						\
>> +{										\
>> +	struct da_monitor *mon = da_mon_##name;					\
>> +	int i;									\
>> +	for (i = 0; i < MAX_PID; i++)						\
>> +		da_monitor_reset_##name(&mon[i]);				\
>> +}										\
>> +										\
>> +static void da_monitor_init_##name(void)					\
>> +{										\
>> +	struct da_monitor *mon = da_mon_##name;					\
>> +	int i;									\
>> +										\
>> +	for (i = 0; i < MAX_PID; i++) {						\
>> +		mon[i].curr_state = model_get_init_state_##name();		\
>> +		mon[i].monitoring = 0;						\
>> +		mon[i].model = model_get_model_##name();			\
>> +	}									\
>> +}										\
>