On 05/22/2014 05:01 PM, Umut Tezduyar Lindskog wrote: > On Thu, May 22, 2014 at 9:07 AM, Lennart Poettering > <lenn...@poettering.net> wrote: >> On Thu, 22.05.14 08:42, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: >> >>> >>> On Thu, May 22, 2014 at 2:18 AM, Lennart Poettering >>> <lenn...@poettering.net> wrote: >>>> On Wed, 21.05.14 14:02, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: >>>> >>>>> >>>>> Hi Cho, >>>>> >>>>> Do you have any technical reason why CPU shares are reverted back to >>>>> the default value on "StartupFinished" but instead when the unit is in >>>>> "activated" state? >>>> >>>> Well, the startup is only considered finished when the default target is >>>> reached, which usually means that all units the target pulled in are >>>> actually in activated state. >>> >>> I believe you haven't had time to look at the rest of the thread. I >>> tried to explain it a bit more here: >>> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019377.html >> >> I did. But again, the StartupFinished signal is sent out after all jobs >> have been processed, and the job queue is empty for the first time. But >> this will only happen if *every single* job that was queued before >> actually went though its "activating" state and is not in >> "active". Hence there's really no point in waiting for any individual >> unit's state change, since looking at the system-wide state is enough >> and incorporates the individual unit's state changes > > :) I don't think we are on the same page. > > When a single unit becomes "active" why would we wait for other units > to become "active" too before we change the cpu share to the default > value. Services can change how long they are going to be in > "activating" state with sd_notify anyways. > > With my propse, we don't do anything on StartupFinished but revert > back the cpu share of a service as soon as it becomes active. > > Propose: > Activating A > Activating B > Set StartupCPUShares on A > Set StartupCPUShares on B > A becomes active > Revert StartupCPUShares with CPUShares on A > B becomes active > Revert StartupCPUShares with CPUShares on B > No more jobs > Send StartupFinished > > Currently: > Activating A > Activating B > Set StartupCPUShares on A > Set StartupCPUShares on B > A becomes active > B becomes active > No more jobs > Revert StartupCPUShares with CPUShares on A > Revert StartupCPUShares with CPUShares on B > Send StartupFinished
On my focus, the Startup* option is designed to balance during systemd being started up(on 'starting' state). The 'Startup' does not mean state of each unit. It means system state what Lennart said. Easily, that can be represented by system is reached to default.target or not. Assume the Startup option work like you propose, if a task is entered to 'active' early then the unit will be changed to NOT Startup weight. And most of tasks has short activating state time better than active time. So Startup will not have much effect. In worst case, some of units can be remained as activating state, even if system is entered to 'running' state, then that will have still Startup weight. It looks doesn't make sense. WaLyong > > Umut > >> >> Lennart >> >> -- >> Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
