From: Peter Zijlstra <peterz@infradead.org>
To: Abel Wu <wuyun.abel@bytedance.com>
Cc: Chen Yu <yu.c.chen@intel.com>, Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Tim Chen <tim.c.chen@intel.com>,
Tiwei Bie <tiwei.btw@antgroup.com>,
Honglei Wang <wanghonglei@didichuxing.com>,
Aaron Lu <aaron.lu@intel.com>, Chen Yu <yu.chen.surf@gmail.com>,
linux-kernel@vger.kernel.org,
kernel test robot <oliver.sang@intel.com>
Subject: Re: [RFC PATCH] sched/eevdf: Return leftmost entity in pick_eevdf() if no eligible entity is found
Date: Mon, 8 Apr 2024 14:00:45 +0200 [thread overview]
Message-ID: <20240408120045.GG21904@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <63102e0a-8a16-4b1d-b8f8-d9833079c924@bytedance.com>
On Fri, Mar 01, 2024 at 04:42:43PM +0800, Abel Wu wrote:
> After a second thought, this doesn't solve the insane huge vruntime
> itself. Since the immediate problem is that 'huge' number actually is
> a small one, is it possible to make vruntime s64 at definition?
In part that was never done because wrapping of signed types in C is UB
and UBSAN used to be buggy. But also, given how it all works, it mostly
doesn't matter.
next prev parent reply other threads:[~2024-04-08 12:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 8:23 [RFC PATCH] sched/eevdf: Return leftmost entity in pick_eevdf() if no eligible entity is found Chen Yu
2024-02-28 9:04 ` Xuewen Yan
2024-02-28 15:24 ` Chen Yu
2024-02-29 12:10 ` Xuewen Yan
2024-03-01 6:46 ` Chen Yu
2024-02-29 9:00 ` Abel Wu
2024-03-01 7:07 ` Chen Yu
2024-03-01 8:42 ` Abel Wu
2024-04-08 12:00 ` Peter Zijlstra [this message]
2024-04-08 11:58 ` Peter Zijlstra
2024-04-08 13:11 ` Chen Yu
2024-04-09 9:21 ` Peter Zijlstra
2024-04-15 7:22 ` Peter Zijlstra
2024-04-15 8:03 ` Chen Yu
2024-04-17 18:34 ` Chen Yu
2024-04-18 2:57 ` Xuewen Yan
2024-04-18 3:08 ` Chen Yu
2024-04-18 3:37 ` Tianchen Ding
2024-04-18 5:52 ` Chen Yu
2024-04-18 6:16 ` Tianchen Ding
2024-04-18 13:03 ` Chen Yu
2024-04-18 23:45 ` Tim Chen
2024-04-19 8:24 ` Peter Zijlstra
2024-04-19 8:45 ` Peter Zijlstra
2024-04-19 9:20 ` Xuewen Yan
2024-04-19 9:17 ` Xuewen Yan
2024-04-19 10:04 ` Chen Yu
2024-04-19 16:24 ` Peter Zijlstra
2024-04-19 17:22 ` Chen Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240408120045.GG21904@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aaron.lu@intel.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oliver.sang@intel.com \
--cc=tim.c.chen@intel.com \
--cc=tiwei.btw@antgroup.com \
--cc=vincent.guittot@linaro.org \
--cc=wanghonglei@didichuxing.com \
--cc=wuyun.abel@bytedance.com \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.