[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4285bef-c4f7-4679-87ab-788dd7fef661@arm.com>
Date: Thu, 24 Apr 2025 18:11:09 +0100
From: James Morse <james.morse@....com>
To: Fenghua Yu <fenghuay@...dia.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Cc: Reinette Chatre <reinette.chatre@...el.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
Babu Moger <Babu.Moger@....com>, shameerali.kolothum.thodi@...wei.com,
D Scott Phillips OS <scott@...amperecomputing.com>,
carl@...amperecomputing.com, lcherian@...vell.com,
bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
dfustini@...libre.com, amitsinght@...vell.com,
David Hildenbrand <david@...hat.com>, Rex Nie <rex.nie@...uarmicro.com>,
Dave Martin <dave.martin@....com>, Koba Ko <kobak@...dia.com>,
Shanker Donthineni <sdonthineni@...dia.com>
Subject: Re: [PATCH v8 17/21] x86,fs/resctrl: Move the resctrl filesystem code
to live in /fs/resctrl
Hi Fenghua,
On 15/04/2025 01:27, Fenghua Yu wrote:
> On 4/11/25 09:42, James Morse wrote:
>> Resctrl is a filesystem interface to hardware that provides cache
>> allocation policy and bandwidth control for groups of tasks or CPUs.
>>
>> To support more than one architecture, resctrl needs to live in /fs/.
>>
>> Move the code that is concerned with the filesystem interface to
>> /fs/resctrl.
>> diff --git a/fs/resctrl/pseudo_lock_trace.h b/fs/resctrl/pseudo_lock_trace.h
>> index e69de29bb2d1..7a6a1983953a 100644
>> --- a/fs/resctrl/pseudo_lock_trace.h
>> +++ b/fs/resctrl/pseudo_lock_trace.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM resctrl
>> +
>> +#if !defined(_X86_RESCTRL_PSEUDO_LOCK_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _X86_RESCTRL_PSEUDO_LOCK_TRACE_H
>> +
>> +#include <linux/tracepoint.h>
>> +
>> +#endif /* _X86_RESCTRL_PSEUDO_LOCK_TRACE_H */
>> +
>> +#undef TRACE_INCLUDE_PATH
>> +#define TRACE_INCLUDE_PATH .
>> +
>> +#define TRACE_INCLUDE_FILE pseudo_lock_trace
>> +
>> +#include <trace/define_trace.h>
> If applying patch 1-17, building the kernel reports this error, which will cause bisect
> failure:
>
> CC fs/resctrl/pseudo_lock.o
> In file included from fs/resctrl/pseudo_lock_trace.h:17,
> from fs/resctrl/pseudo_lock.c:35:
> ./include/trace/define_trace.h:110:42: fatal error: ./pseudo_lock_trace.h: No such file or
> directory
> 110 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
> | ^
> compilation terminated.
> make[4]: *** [scripts/Makefile.build:203: fs/resctrl/pseudo_lock.o] Error 1
>
> Again combining patch 18 with this patch together makes the error go away.
>
> But you said combining them together may cause the conversion python tool complex:
> https://lore.kernel.org/lkml/97aeaf87-b2db-4efb-9d81-43769c6f27b0@arm.com/
>
> Is there a better way to resolve this error? Maybe update the tool not to generate or
> include fs/resctrl/pseudo_lock_trace.h at all?
Please see my previous description of this, also described in the cover letter:
| Patches X-Y should be squashed together when merged - they are posted like
| this to allow folk to re-generate patch N, then review the differences on
| op. Not squashing them together would expose a ftrace build warning
| during bisect. (but who does that!)
| That would look like this:
| git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v8_final
Amusingly, I forgot to fix 'X-Y', that should read as 17-21.
I can post that 'final' version with everything squashed together once patches 18-21 have
been reviewed - but doing that before makes it harder to review the deliberate changes
separately from the mechanical changes. This patch is just the mechanical changes.
Thanks,
James
Powered by blists - more mailing lists