Date: Wed, 03 Jun 2020 08:51:03 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246940] [wishlist/enhancement, patch incl.]: idle user tasks should be charged as "nice" or "idle" CPU time Message-ID: <bug-246940-227-RSwLztvhD9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246940-227@https.bugs.freebsd.org/bugzilla/> References: <bug-246940-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246940 --- Comment #7 from t.eichstaedt@gmx.net --- (In reply to Conrad Meyer from comment #6) Good morning, and thx for your time. >> [mixed up nice & priority] > This is a misunderstanding. Nice and priority are orthogonal. OK I'll try harder to be more precise and choose the right verbs. >> [my assumption: load values ~ runtime sched classes] > This is also a misunderstanding; it isn't the categorization used by cp_t= imes. > [...] That's it. OK. Got that. Wrong assumption/association. > I think it would be reasonable to collect and expose the data you want, [= ...] I'm glad to hear that. Do you mean to weave in the computations to update a modern clone of cp_time, with additional fields for the non-traditional (so= ft) realtime & user_idle classes, into the "if(usermode)"-branch of statclock()? And clone the resp. SYSCTL_PROCs for the overall and per-cpu cp_time(s)? Is it possible to simply add a flag to the existing one and use the very sa= me function for both sysctl's? Or do we need a wrapper function? These functio= ns seem to be so simple, I'd resist to copy&paste when all that's different is= the number of fields in an array. Is there an implicit mutex or lock set by one= of these SYSCTL_XXX macros? I have no clue about these SYSCTL things... if you want do that because it's trivial and useful anyway, I'm happy. If you wan= t to let me do it instead, because I'm the only one asking for it, I'll dive int= o it and come up with a suggestion. Would that need to be against the FBSD-13_CURRENT src? > If we want to provide a better laptop experience, it needs to work out of= the > box. +++ IMHO we can assume laptop users enable powerd or such, and others do no= t. > (=E2=80=A0): User-driven frequency scaling is kind of a losing game at th= is point, > especially with powerd. Idle C-states consume almost nothing regardless = of > frequency. When any other except the kernel idle task is running, the cpu is in the C0 state, right? So the states >=3DC1 are not reached as long there's some ta= sk ready to run, because the scheduler picks it up to let it run, right? Thus= , to achieve what I consider ("cool" user_idle tasks), the runtime scheduler had= to provide a mechanism to artificially "retard" an (or all) idle user task, i.= e. give it less time slices (less often), which it currently does not do on an otherwise idle system. I'm not aware of such a mechanism. The implicit assumption of the scheduler is to get all work done, optimized and parameterized for a mix of speed, throughput and (by architecture) "fairnes= s", and it has no notion neither for ernergy efficiency nor absolute power consumption. If you suggest the better solution would be to update the scheduler instead, I'd be interested as well, but probably that's beyond my current skills. More likely than not. Anyway, it'd be much more complicat= ed and - foremost - dangerous. Regarding power consumption, the cpu freq is the dominating factor (in C0 state). That's basic physics. Am I wrong here? Freq scaling based on load values is what exists and will be in use for the lifetime of today's machin= es.=20 If you can point me to what powerd does methodically wrong (other than the mentioned handling of independant cores), feel free to do so. Likewise, any other better solution - I welcome your hints. > Powerd doesn't know how to manage frequency on multiple independent CPUs. I'll have a look at that. Is this possible on a one-package two-core SMT system? I have a Core i7-5600U, that's what I can test on bare metal. The= se things never interested me more than to survive a test at the univ. Obviou= sly two virtual SMT cores on one physical core can not have different freqs. T= he rest is what I "just use", but if I have to dive into that, I'll do so.=20 > Intel is moving away from OS-driven p-states entirely; future CPUs will s= imply=20 > not support it. (Instead, cores can be set to an energy efficiency > profile on some 0-100 percentage scale.) Sounds like KISS. It's important to support new hardware, but it's also fa= ir to support existing hw during it's lifetime. Let's say, two decades. Sorry for the lengthy mail - I want to have this going (i.e. "cool" user_id= le). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246940-227-RSwLztvhD9>