Re: KCGroups in KDEreview
I opened an issue in line with the new kdereview process
https://invent.kde.org/libraries/kcgroups/-/issues/1
Jonathan
On Sat, 21 Nov 2020 at 00:38, Albert Astals Cid wrote:
> El divendres, 20 de novembre de 2020, a les 14:55:16 CET, Henri Chain va
> escriure:
> > Hello everyone,
> >
> > KCgroups has been moved to KDEReview !
> > What is that, you ask ? It's a library that wraps the systemd dbus API
> to
> > expose a higher-level concept of desktop application and allow control
> of its
> > system resource usage (CPU, RAM, IO, etc).
> >
> > It relies on the recent ability of plasma to launch applications in
> their own
> > systemd scopes, with correspond to cgroups and provides a more robust
> > definition for an application (more details at
> https://lwn.net/Articles/834329/
> > ) .
> >
> > The main use of the library is to expose related resource control
> settings for
> > those applications, at a user space level that other KDE applications
> and
> > frameworks can use, including consumption straight from QML as
> demonstrated in
> > the test application.
> >
> > KCgroups is intended to become a (Tier 1) framework. A first user of
> this
> > library might be the foreground window CPU booster daemon that is
> available
> > here:
> https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> >
> > Packages are already available for both Neon and Arch Linux.
> >
> > Looking forward to your feedback and ideas for using this,
>
> I'm a bit scared about your optional class being there all in the main
> namespace. I'd suggest putting in some "namespace kcgroups{}" or name it
> kcgoptional or something.
>
> you have a few properties without NOTIFY, ideally you should either add it
> if they can change or mark them as CONSTANT if they can't.
>
> Cheers,
> Albert
>
>
> > Henri
> >
> >
> >
>
>
>
>
>
Re: KCGroups in KDEreview
Hello, On Tuesday, 2 March 2021 12:06:51 CET David Edmundson wrote: > > > (where 1000 is of course dynamic) > > > > Ditto, what enum names could we give to those? > > / -> All > /system.slice -> System > user.slice/user-1000.slice/user@1000.service -> User > user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps > user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession > user.slice/user-1000.slice/user@1000.service/background.slice -> > UserBackground Sounds good to me. Let's go for this. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
> > (where 1000 is of course dynamic) > > Ditto, what enum names could we give to those? / -> All /system.slice -> System user.slice/user-1000.slice/user@1000.service -> User user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession user.slice/user-1000.slice/user@1000.service/background.slice -> UserBackground > Yes, I know I roll with questions. :-) > Cheers. > -- > Kevin Ottens, http://ervin.ipsquad.net
Re: KCGroups in KDEreview
On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote: > On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > > Ultimately this isn't really dealing with cgroups directly but with > > > the manager to control them, systemd. > > > > > > That's correct usage, kernel docs of cgroups say to go via a > > > controller for write operations. However that at point is it worth > > > naming the library ksystemd? > > > It might cause some contention due to people who get angsty at a name, > > > but it's a lot more fitting. It would then give us a place to dump a > > > lot of other wrappers (especially logind) that we're seeing duplicated > > > in a bunch of places throughout KDE. > > > > Aren't you concerned this might lead to one of our infamous dumping > > grounds? > > > > There's always a tension between making it too focused and tiny or > > unfocused and with blackhole mass... we'd need to find where it stands > > but "systemd wrappers" looks too loosely defined to me. > > > > > > Do we have a list of the wrappers you got in mind and which piece of > > feature they all provide? > > StartUnit, given this has a StopUnit > Used by plasma-workspace and plasma-firewall > > Logind I have wrappers in: > - kwin > - libkworkspace > - SDDM > - powerdevil > - kscreenlocker > > None wrapping all of it, only what they need, but there's still overlap. > You're right that could be a separate framework if that's preferred. I'll be honest I'm still unsure what that'd mean in practice... What about drafting API for a couple of those? Let's not get overboard implementing stuff and so on, it's more exploratory that anything for now. > > > I think we've artificially limited the usage of the library. > > > The code is very generic for handling units, but all the names and one > > > tiny line limit it to only managing a subset of units. > > > > > > If we make the "glob" static used in KApplicationScopeLister's have a > > > public setter (or a protected virtual) we can rename this class and it > > > becomes a much more generic library for others to use outside of any > > > initial use-case. > > > > Good point. Got a similar question though, which other unit types would be > > useful to control? Reason being that API wise I'd smell an enum for > > something like this. > > Enum potentially works too. > > Describing things in terms of cgroup hierarchy, I think the key use cases > are: > > / > user.slice/user-1000.slice/user@1000.service > user.slice/user-1000.slice/user@1000.service/app.slice > user.slice/user-1000.slice/user@1000.service/session.slice > user.slice/user-1000.slice/user@1000.service/background.slice > (where 1000 is of course dynamic) Ditto, what enum names could we give to those? Yes, I know I roll with questions. :-) Cheers. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > Ultimately this isn't really dealing with cgroups directly but with > > the manager to control them, systemd. > > > > That's correct usage, kernel docs of cgroups say to go via a > > controller for write operations. However that at point is it worth > > naming the library ksystemd? > > It might cause some contention due to people who get angsty at a name, > > but it's a lot more fitting. It would then give us a place to dump a > > lot of other wrappers (especially logind) that we're seeing duplicated > > in a bunch of places throughout KDE. > > Aren't you concerned this might lead to one of our infamous dumping grounds? > > There's always a tension between making it too focused and tiny or unfocused > and with blackhole mass... we'd need to find where it stands but "systemd > wrappers" looks too loosely defined to me. > > Do we have a list of the wrappers you got in mind and which piece of feature > they all provide? StartUnit, given this has a StopUnit Used by plasma-workspace and plasma-firewall Logind I have wrappers in: - kwin - libkworkspace - SDDM - powerdevil - kscreenlocker None wrapping all of it, only what they need, but there's still overlap. You're right that could be a separate framework if that's preferred. > > > I think we've artificially limited the usage of the library. > > The code is very generic for handling units, but all the names and one > > tiny line limit it to only managing a subset of units. > > > > If we make the "glob" static used in KApplicationScopeLister's have a > > public setter (or a protected virtual) we can rename this class and it > > becomes a much more generic library for others to use outside of any > > initial use-case. > > Good point. Got a similar question though, which other unit types would be > useful to control? Reason being that API wise I'd smell an enum for something > like this. Enum potentially works too. Describing things in terms of cgroup hierarchy, I think the key use cases are: / user.slice/user-1000.slice/user@1000.service user.slice/user-1000.slice/user@1000.service/app.slice user.slice/user-1000.slice/user@1000.service/session.slice user.slice/user-1000.slice/user@1000.service/background.slice (where 1000 is of course dynamic)
Re: KCGroups in KDEreview
>From a user's point of view (who helps with triaging bugs and some other stuff from time to time), so feel free to consider it or not. David Edmundson - 03.12.20, 12:15:52 CET: > Ultimately this isn't really dealing with cgroups directly but with > the manager to control them, systemd. > > That's correct usage, kernel docs of cgroups say to go via a > controller for write operations. However that at point is it worth > naming the library ksystemd? I'd say that depends on whether it at some point could be extended to support another cgroups controller daemon or not. I don't see any popular one at this point in time, however this might change. > It might cause some contention due to people who get angsty at a name, > but it's a lot more fitting. It would then give us a place to dump a > lot of other wrappers (especially logind) that we're seeing > duplicated in a bunch of places throughout KDE. Of course if you like to extend it more towards systemd, a name change would make sense. While I know and teach what control groups can do, I do not really care about the functionality they offer at the moment on my desktop machines. I use elogind with Plasma both on Debian Sid and on Devuan Ceres which sets up a CGroup V2 structure by default, but does not do any of the resource control stuff that Systemd offers. Control groups, logind and things like that sounds like integration with services and functionalities of the host operating system. So I wondered whether it would make sense to generalize that. However, that might just be too much abstraction. There is Phonon, which does that for audio, but basically I just used whatever backend was recommended at a time. And AFAIR there has been times where one of the backends did not even work correctly for some reason. Ciao, -- Martin
Re: KCGroups in KDEreview
On Thu, Dec 3, 2020 at 12:48 PM Kevin Ottens wrote: > > Good point. Got a similar question though, which other unit types would be > useful to control? Reason being that API wise I'd smell an enum for something > like this. > Well if this library would evolve towards C++ API for interacting with systemd, then the following could potentially be useful: - *.timer (cron jobs) - *.scope (confinement to a cgroup) - *.slice (resource partitioning between cgroups) - *.mount (mount options for filesystems) - *.automount (automatically activating a mount for plug and play removable storage without too much fsck risk) - *.service (managing background services) - *.socket (in case your services do things with socket based activation, e.g. dbs) Some of these are obviously already covered, but because I'm not familiar with the KCGroups code base I just listed them for the sake of completeness. Covering them all would give you the basic building block for a GUI for systemd more generally. Additionally, if the "all the wrappers included" approach is taken it might eventually also be worth considering systemd-homed (portable user directories backed by encrypted storage). Regards, - Johan Ouwerkerk
Re: KCGroups in KDEreview
Hello, On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > Ultimately this isn't really dealing with cgroups directly but with > the manager to control them, systemd. > > That's correct usage, kernel docs of cgroups say to go via a > controller for write operations. However that at point is it worth > naming the library ksystemd? > It might cause some contention due to people who get angsty at a name, > but it's a lot more fitting. It would then give us a place to dump a > lot of other wrappers (especially logind) that we're seeing duplicated > in a bunch of places throughout KDE. Aren't you concerned this might lead to one of our infamous dumping grounds? There's always a tension between making it too focused and tiny or unfocused and with blackhole mass... we'd need to find where it stands but "systemd wrappers" looks too loosely defined to me. Do we have a list of the wrappers you got in mind and which piece of feature they all provide? > I think we've artificially limited the usage of the library. > The code is very generic for handling units, but all the names and one > tiny line limit it to only managing a subset of units. > > If we make the "glob" static used in KApplicationScopeLister's have a > public setter (or a protected virtual) we can rename this class and it > becomes a much more generic library for others to use outside of any > initial use-case. Good point. Got a similar question though, which other unit types would be useful to control? Reason being that API wise I'd smell an enum for something like this. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
Ultimately this isn't really dealing with cgroups directly but with the manager to control them, systemd. That's correct usage, kernel docs of cgroups say to go via a controller for write operations. However that at point is it worth naming the library ksystemd? It might cause some contention due to people who get angsty at a name, but it's a lot more fitting. It would then give us a place to dump a lot of other wrappers (especially logind) that we're seeing duplicated in a bunch of places throughout KDE. --- I think we've artificially limited the usage of the library. The code is very generic for handling units, but all the names and one tiny line limit it to only managing a subset of units. If we make the "glob" static used in KApplicationScopeLister's have a public setter (or a protected virtual) we can rename this class and it becomes a much more generic library for others to use outside of any initial use-case. David
Re: KCGroups in KDEreview
Hello, On Friday, 20 November 2020 14:55:16 CET Henri Chain wrote: > KCgroups has been moved to KDEReview ! > What is that, you ask ? It's a library that wraps the systemd dbus API to > expose a higher-level concept of desktop application and allow control of > its system resource usage (CPU, RAM, IO, etc). > > It relies on the recent ability of plasma to launch applications in their > own systemd scopes, with correspond to cgroups and provides a more robust > definition for an application (more details at > https://lwn.net/Articles/834329/ ) . > > The main use of the library is to expose related resource control settings > for those applications, at a user space level that other KDE applications > and frameworks can use, including consumption straight from QML as > demonstrated in the test application. > > KCgroups is intended to become a (Tier 1) framework. A first user of this > library might be the foreground window CPU booster daemon that is available > here: > https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster > > Packages are already available for both Neon and Arch Linux. > > Looking forward to your feedback and ideas for using this, Glad to see this come to fruition. One concern regarding use with other libraries: * the OPTIONAL_GADGET use introduce names that I could see potentially clashing with application code or code in third party libraries, I wonder if they should be moved in a namespace as well (as in "like optional") or have a K name at least; Minor things I found: * tests/main.cpp needs to have some of its includes cleaned up (at a glance QDebug and QTimer aren't needed there); * tests/main.qml should have better ids for its elements IMHO, often those manual tests end up used as examples by people and having better readability helps (also avoids having people copying and pasting shameful things). ;-) That's not much but I'm obviously biased by the fact that we discussed this API together already. :-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
On Saturday, November 21, 2020 1:38:47 AM CET Albert Astals Cid wrote:
> El divendres, 20 de novembre de 2020, a les 14:55:16 CET, Henri Chain va
escriure:
> > Hello everyone,
> >
> > KCgroups has been moved to KDEReview !
> > What is that, you ask ? It's a library that wraps the systemd dbus API to
> > expose a higher-level concept of desktop application and allow control of
> > its system resource usage (CPU, RAM, IO, etc).
> >
> > It relies on the recent ability of plasma to launch applications in their
> > own systemd scopes, with correspond to cgroups and provides a more robust
> > definition for an application (more details at
> > https://lwn.net/Articles/834329/ ) .
> >
> > The main use of the library is to expose related resource control settings
> > for those applications, at a user space level that other KDE applications
> > and frameworks can use, including consumption straight from QML as
> > demonstrated in the test application.
> >
> > KCgroups is intended to become a (Tier 1) framework. A first user of this
> > library might be the foreground window CPU booster daemon that is
> > available
> > here:
> > https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> >
> > Packages are already available for both Neon and Arch Linux.
> >
> > Looking forward to your feedback and ideas for using this,
>
> I'm a bit scared about your optional class being there all in the main
> namespace. I'd suggest putting in some "namespace kcgroups{}" or name it
> kcgoptional or something.
Fixed in https://invent.kde.org/libraries/kcgroups/-/commit/
1e0a6576a75b3f1f94ee62cf24e1818ace739e29 .
The optional implementation was intended to be a stopgap for c++14 and be
fully compatible with the std implementation. I put it in its own namespace,
and changed the includes to use the std implementation when available
>
> you have a few properties without NOTIFY, ideally you should either add it
> if they can change or mark them as CONSTANT if they can't.
Clazy reports warnings mostly on the interfaces generated by qtdbusxml2cpp.
The NOTIFYs are truly missing from the underlying dbus interface, which is a
design choice of systemd (and they aren't constant either). There was one
missing CONSTANT which was my fault however, fixed that in https://
invent.kde.org/libraries/kcgroups/-/commit/
d2130d24587a01237c892cfc4602e59102104e66
Thanks for the review!
Henri
>
> Cheers,
> Albert
>
> > Henri
Re: KCGroups in KDEreview
On Friday, November 20, 2020 8:29:33 PM CET Jacky Alcine wrote: > This is exciting! Is it needed to explicitly put "cgroups" in the name? > (What I'm really asking is if there's a way to have this work in a > cross-platform way) Yes, this library takes advantage of cgroups resource control, and nothing truly comparable exists outside of linux. It does so by leveraging systemd which is also a requirement. The process grouping part can probably be ported however. Windows and Mac OS X both have this kind of thing, but it might require escalation. I currently don't have plans to make this a platform independent library but it could be a long term goal. > On Fri, Nov 20, 2020, at 05:55, Henri Chain wrote: > > Hello everyone, > > > > KCgroups has been moved to KDEReview ! > > What is that, you ask ? It's a library that wraps the systemd dbus API to > > expose a higher-level concept of desktop application and allow control of > > its system resource usage (CPU, RAM, IO, etc). > > > > It relies on the recent ability of plasma to launch applications in their > > own systemd scopes, with correspond to cgroups and provides a more robust > > definition for an application (more details at > > https://lwn.net/Articles/834329/ ) . > > > > The main use of the library is to expose related resource control settings > > for those applications, at a user space level that other KDE applications > > and frameworks can use, including consumption straight from QML as > > demonstrated in the test application. > > > > KCgroups is intended to become a (Tier 1) framework. A first user of this > > library might be the foreground window CPU booster daemon that is > > available > > here: > > https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster > > > > Packages are already available for both Neon and Arch Linux. > > > > Looking forward to your feedback and ideas for using this, > > Henri
Re: KCGroups in KDEreview
This is exciting! Is it needed to explicitly put "cgroups" in the name? (What I'm really asking is if there's a way to have this work in a cross-platform way) On Fri, Nov 20, 2020, at 05:55, Henri Chain wrote: > Hello everyone, > > KCgroups has been moved to KDEReview ! > What is that, you ask ? It's a library that wraps the systemd dbus API to > expose a higher-level concept of desktop application and allow control of its > system resource usage (CPU, RAM, IO, etc). > > It relies on the recent ability of plasma to launch applications in their own > systemd scopes, with correspond to cgroups and provides a more robust > definition for an application (more details at > https://lwn.net/Articles/834329/ > ) . > > The main use of the library is to expose related resource control settings > for > those applications, at a user space level that other KDE applications and > frameworks can use, including consumption straight from QML as demonstrated > in > the test application. > > KCgroups is intended to become a (Tier 1) framework. A first user of this > library might be the foreground window CPU booster daemon that is available > here: https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster > > Packages are already available for both Neon and Arch Linux. > > Looking forward to your feedback and ideas for using this, > Henri > > >
Re: KCGroups in KDEreview
El divendres, 20 de novembre de 2020, a les 14:55:16 CET, Henri Chain va
escriure:
> Hello everyone,
>
> KCgroups has been moved to KDEReview !
> What is that, you ask ? It's a library that wraps the systemd dbus API to
> expose a higher-level concept of desktop application and allow control of its
> system resource usage (CPU, RAM, IO, etc).
>
> It relies on the recent ability of plasma to launch applications in their own
> systemd scopes, with correspond to cgroups and provides a more robust
> definition for an application (more details at
> https://lwn.net/Articles/834329/
> ) .
>
> The main use of the library is to expose related resource control settings
> for
> those applications, at a user space level that other KDE applications and
> frameworks can use, including consumption straight from QML as demonstrated
> in
> the test application.
>
> KCgroups is intended to become a (Tier 1) framework. A first user of this
> library might be the foreground window CPU booster daemon that is available
> here: https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
>
> Packages are already available for both Neon and Arch Linux.
>
> Looking forward to your feedback and ideas for using this,
I'm a bit scared about your optional class being there all in the main
namespace. I'd suggest putting in some "namespace kcgroups{}" or name it
kcgoptional or something.
you have a few properties without NOTIFY, ideally you should either add it if
they can change or mark them as CONSTANT if they can't.
Cheers,
Albert
> Henri
>
>
>
