[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <357e2c84-7b60-4ad7-8511-a8415999174d@igalia.com>
Date: Fri, 14 Feb 2025 16:07:33 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Tejun Heo <tj@...nel.org>
Cc: void@...ifault.com, arighi@...dia.com, kernel-dev@...lia.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: Provides a sysfs 'events' to expose core event
counters
Hello Tejun,
Thank you for the review!
On 25. 2. 14. 01:45, Tejun Heo wrote:
> Hello, sorry about the late reply.
>
> On Tue, Feb 11, 2025 at 09:57:08AM +0900, Changwoo Min wrote:
>>> This probably should belong to the root/ subdir as we'd probably want to
>>> keep the event counter separate per scheduler instance in the
>>> multi-scheduler future.
>>
>> I feel this is a bit contradictory to the need to access the core
>> event counters even after an scx scheduler is unloaded. In the
>> current implementation, root/ subdir appears and disappears when
>> an scx scheduler is loaded and unloaded.
>>
>> We may change the scx_ktype to something similar to
>> scx_global_attr_group in order to keep root/ subdir. We then show
>> an empty file for root/ops when no scx scheduler is loaded while
>> keep the root/events file intact. I am not sure if this is what
>> we want.
>>
>> What do you think?
>
> Hmm... I don't think we can keep the directory for counters of schedulers
> that have been unloaded. Looks like the right thing to do is giving up on
> the idea of being able to access the counters after the scheduler is
> unloaded. The counters are dumped on error exits, so hopefully this isn't
> too big a loss. What do you think?
Yes, dumping the event counters is a part of scx_dump_state().
I agree. That's a reasonable choice. I will move 'events' under
the root/ subdir and send out a new version.
Regards,
Changwoo Min
Powered by blists - more mailing lists