From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58E9323C9 for ; Sat, 18 Jan 2025 00:27:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.60.130.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737160054; cv=none; b=vBdVNy5poOSSGH/sHBPOiOWgc0j6rxpauUhgiraR2fJj72SIXnmfLwFbHWqYtnKYwVwq1y86BNu83Wh8aWdJfJmqz1A7SEq/IzQuhjXMyQgDAykqD15Iy7intoU6oe68PGssBmzE+Bad2eFshWtOUX0IT/2DKMbph9yNbQ6s/gc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737160054; c=relaxed/simple; bh=VRIPpGbVVlx4oW+Mxq5O+0nI8YP3t9+I7j0+nZHfBDM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OnLL2kM8AnVf/Za9aG67xpjMc5IIXeIII5/RCPH4ZX3VYRqMxOlk5Ml45rdjoreriAz+NP1doVGMwFSnWv6/l71rIauEvUMwZh/dZslKFt73V7WRCPTTapuQXqnGJHD5uZTFfEMDfrMg1QxU3EJsCaagNgcHew9OqsfJLyzKWvY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=TgPunfEK; arc=none smtp.client-ip=178.60.130.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="TgPunfEK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=j4QyYQzpZ8KXdM+eI06f+XKoppnjGSYX0eqRBc/qKu0=; b=TgPunfEKA7kXEACvOEXxORf9yl 7WjORFbkuo8qq0YUR3nJ6BsQ1zX6726wmDLMY+rcxtqH9jAGfDm2Jfy06ck/8/WwdHaJHAfE9aKtW xt+7hbyTzaQKFyBG53Aa2+8saTjpX7UXCGr/v7sD2u2FYMLBJYMvFMTShUsq8CM0vKwqQjtItHTZA Xw6iJr6ttoc7HW0I06hikxi8hcQB1wmUSZj/j5f86q+1duLmBEYCSz4RaHahmHDstyhtpUwhUu13e A3JuUokQs1GkJq+hxuuxT8UabheT/njt4XCN175Zvb3FBeH9n02GCM6q7IALQFXHMhvQs2Hyb+zJh HN7u78qg==; Received: from [58.29.143.236] (helo=[192.168.1.6]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1tYwgN-00HOla-Q8; Sat, 18 Jan 2025 01:27:24 +0100 Message-ID: <0c77afb9-1768-4141-8d92-d38097c4df0b@igalia.com> Date: Sat, 18 Jan 2025 09:27:18 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/7] sched_ext: Implement event counter infrastructure and add an event To: Tejun Heo Cc: void@manifault.com, arighi@nvidia.com, kernel-dev@igalia.com, linux-kernel@vger.kernel.org References: <20250116151543.80163-1-changwoo@igalia.com> <20250116151543.80163-2-changwoo@igalia.com> <16a9e631-22c0-454a-b56f-c5206ec3d1dc@igalia.com> From: Changwoo Min Content-Language: en-US, ko-KR, en-US-large, ko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, On 25. 1. 18. 01:24, Tejun Heo wrote: >> second approach is satisfactory regarding the BPF binary >> compatibility by CO-RE. However, it is a little bit cumbersome to >> iterate all the events, so I added the enums. I know the enums >> are only usable in the kernel code due to the binary >> compatibility, but I thought adding the enums rather than >> bloating the scx_dump_state() code at the end would be better. >> Does it make sense to you? > > Let's just use the structs and open code dumping. We can pack the dump > output better that way too and I don't think BPF scheds would have much use > for enum iterations. Currently, enums are not exposed to BPF schedulers. Also, BPF schedulers should not rely on the enums because the enums are coupled with a specific layout of the struct, so that would cause a BPF binary compatibility problem. Could you explain more on the code dumping? I want at least print the event string for easier interpretation. > ... >>>> +/** >>>> + * scx_add_event - Increase an event counter for 'name' by 'cnt' >>>> + * @name: an event name defined in struct scx_event_stat >>>> + * @cnt: the number of the event occured >>>> + */ >>>> +#define scx_add_event(name, cnt) ({ \ >>>> + struct scx_event_stat *__e; \ >>>> + __e = get_cpu_ptr(&event_stats); \ >>>> + WRITE_ONCE(__e->name, __e->name+ (cnt)); \ >>>> + put_cpu_ptr(&event_stats); \ >>> >>> this_cpu_add()? >> >> That's handier. I will change it. > > Note that there's __this_cpu_add() too which can be used from sections of > code that already disables preemption. On x86, both variants cost the same > but on arm __this_cpu_add() is cheaper as it can skip preemption off/on. > Given that most of these counters are modified while holding rq lock, it may > make sense to provide __ version too. Sounds good. I will add __scx_add_event() following the convention of this_cpu_add() and __this_cpu_add(). > > ... >>> Also, I'm not sure this is a useful event to count. False ops_cpu_valid() >>> indicates that the returned CPU is not even possible and the scheduler is >>> ejected right away. What's more interesting is >>> kernel/sched/core.c::select_task_rq() tripping on !is_cpu_allowed() and >>> falling back using select_fallback_rq(). >>> >>> We can either hook into core.c or just compare the ops.select_cpu() picked >>> CPU against the CPU the task ends up on in enqueue_task_scx(). >> >> Modifying core.c will be more direct and straightforward. Also, >> I think it would be better to separate this commit into two: one >> for the infra-structure and another for the SELECT_CPU_FALLBACK >> event, which touches core.c. I will move the necessary code in >> the infrastructure into kernel/sched/sched.h, so we can use >> scx_add_event() in core.c. > > Hmm.... yeah, both approaches have pros and cons but I kinda like the idea > of restricting the events within ext.c and here detecting the fallback > condition is pretty trivial. I don't know. Right, it will be possible track the same thing without touch core.c (that's too much) by replicating the conditions in core.c to ext.c. I will dig the code more to figure out what the best approach is. Regards, Changwoo Min