dCore Import Debian Packages to Mountable SCE extensions > dCore X86
sce-update hi cpu usage
jls:
Hi
If I'm not wrong sce-update is a long process and takes quite a lot of cpu. what do u guys think about adding a nice option in sceconfig?
nitram:
To me adding 'nice' might be nice.
Running sce-update -a is CPU intensive and i've changed my habits accordingly. Import most SCEs dependent on xorg-* (keeps most SCEs small), only update system every 2 weeks unless something critical, re-import xorg-* without bothering update check (re-import almost as fast as an update check, almost twice as fast an an update check then re-import, almost guarantee >1 dependency requires update), reboot to activate, next session run sce-update -a and update remaining smaller SCEs fairly quick, less CPU cycles. The same is probably true for users utilizing large 'base' lists, almost guaranteed several updates in 'base' will be available in a 2 week window, probably faster to re-import every 2 weeks than check for updates then re-import.
Not taking away from the 'nice' request, as jls' query is directly related to sce-update intensity. Reviewed sce-update related scripts and wasn't clear to me. Running sce-update -an user wants everything updated fast, don't care about an updates list. As an SCE's deps are systematically update checked, does it still complete the long process even if a dep update is available?
If so, which i think is the case, can't a re-import immediately be flagged as soon as the first outdated dep is detected, break out of the check loop early and proceed to next SCE? If this isn't already default behaviour for the -n options, it might make a big difference in update check duration. For example, xorg-vesa has 147 dependencies. If the first dep checked was Xprogs and an update was available, the update check would take ~1/147 the amount of time, exit check loop early, flag xorg-vesa for re-import, process next SCE.
Jason W:
I am running the command "nice -19 sce-update -an", and it is very nice indeed to my running system where I am wanting to watch video or use firefox or both. Would be simple to create a wrapper for sce-update and sce-import to use a nice value specified in /etc/sysconfig/sceconfig. I also avoid running sce-update or sce-import when actually using my desktop. Tomorrow I will upload a prototype, where a nice value can be specified in /etc/sysconfig/sceconfig.
As for exiting and flagging an SCE for update on the first found package needing update, it would break the ability to see all that needs updating, but if that info is not really important, we can go that way too.
I will add the nice value tomorrow to test and we can go from there.
Jason W:
The question that remains is do we really need to know all the packages or startup script changes involved in an SCE update? I never needed to know them all, if an SCE needs updating due to changes in Debian/Ubuntu or our files it simply needs updating. My vote is to halt the update check on the first found update need and move on the checking the next SCE just knowing the previous needs updating. But I will listen to all opinions.
nitram:
Thanks for suggesting nice jls and thanks for prototyping Jason - it's all so very, very nice :))
Many users may not care what was updated, just that it's updated efficiently.
This could be incorporated as a feature (-f fast check) so users have choice.
Draft --help or could incorporate into wiki:
--- Code: ---sce-update -f Fast SCE update. Flag SCE(s) for update upon encountering first
outdated dependency. Fast check all SCEs using the -caf flags or
auto-update all using the -af flags. Provides no DEBINX diff or
outdated package list. Workaround for systems that keep
/tce/import/debs/, run sce-debpurge immediately before
and after a fast update to identify deprecated packages.
--- End code ---
Sorry didn't think this was a new feature suggestion, but after thinking it through...
Edit: To clarify, sce-debpurge runs through quickly compared to sce-update.
Navigation
[0] Message Index
[#] Next page
Go to full version