Le Thursday 06 June 2013 à 12:36 -0700, Linda Walsh a écrit :
Jean Delvare wrote:
You claim that none of your systems has the "button" driver loaded?
They will load it -- but it isn't needed... it doesn't do anything. They will work w/o it as well (none of mine are laptops).
This driver is responsible for capturing and routing the power button, sleep button and lid events. Without it, you can't shut down your machine cleanly with the power button. Just try it. Well maybe you don't need this feature, but it is enabled by default and I'm sure most users expect it to work. Disable this feature and users will press the button for 4 seconds and hard shut-down the machine instead. Yes, like Windows users do.
The processor driver depends on thermal_sys, so you can't have the former without the latter.
# ls -d /sys/module/{proc*,therm*} ls: cannot access /sys/module/therm*: No such file or directory /sys/module/processor/
Certainly because you rebuilt your kernel with CONFIG_THERMAL!=m. I wouldn't want to run a kernel without it. We are discussing changes to be done (or not) to the openSUSE kernel flavor config files. Any local configuration change you have already done may lead you to different conclusions which are irrelevant for the discussion. Have you taken the time to read the whole discussion thread?
sg is loaded automatically so you certainly have it.
----
Yes.. I just wasn't sure what it was for.
As discussed somewhere else in this thread, sg may not be needed on all systems, but it is impossible to tell when it is needed and when not. So from the distribution perspective, the choice is between building it as a module and loading it (almost) unconditionally, and building it into the kernel. The only advantages of having it as a module are: to have the possibility to override it with a KMP, and to let advanced users blacklist it (you might actually have to edit the udev rule that loads it) or unload it. I'm not convinced that these advantages are worth the small extra boot time delay for all users.
If you don't use drm, does it mean you have binary graphics drivers everywhere?
----
??? Um... neither of my systems running linux full time run a desktop they both run as servers and only boot up to rc3. My
These days, with KMS, even the console is backed by DRM drivers.
other if it runs linux would try to use a binary nvidia driver... which might use drm, dunno. been a while since I trie.
No, the binary Nvidia driver doesn't use drm.
(...) This isn't the current strategy for openSUSE kernels, sorry. This has been discussed several times in the past. Long story sort: loading modules takes time and uses extra memory, so building everything as a module is not optimal from a performance point of view.
----
That's just plain not true. My system boots considerably faster if I don't boot things that aren't needed.
You system boots faster because you built a custom kernel for it. Nobody is arguing about that. But the discussion I am having here is how to make the default openSUSE kernels boot faster on average.
Microsoft will disagree with you as well as far as user perceptions go and getting to some sort of responsiveness about your system (which isn't the same as talking absolute numbers -- perceptions are what drives the market, not facts).
I did not measure any number when seeing Windows systems starting. My perception is exactly what I reported: the desktop shows up fast, but then it takes a long time before the system is actually usable. What Microsoft (and others) are advertising are actually numbers - desktop appears N seconds after boot, yay! So I'm afraid you god it exactly the wrong way around. What drives the market is, well, marketing, habits, patents and lobbying. Neither perception not facts, I'm afraid. You seem to be a big fan of Microsoft BTW, I'm curious why (but don't get me wrong, still very happy that) you run Linux on your machines ;-)
As a consequence, it was decided that non hardware-specific drivers which are needed on a large majority of systems should be built into the kernel - unless we have a good reason not to.
----
That's why I build my own kernel and have generally until the latest mess with systemd, booted in about half the time as a suse kernel.
This is both interesting and impressive. I know that others at Suse have made such experiments already, sometimes as hackweek projects. Have you been able to isolate the specific kernel components which slowed down boot the most on your systems?
Also note that a few weeks ago I have modularized about 20 drivers which were built-in so far, for specific hardware most people do not have, so it was really wasted boot time and memory for everybody. But nobody (including you) had been paying attention to that before I looked into it. So please don't come and complain now.
----
I didn't complain because they never were in my kernel to begin with ;-).
Fair enough, but I can't recall you thanking me for it either ;-)
I've been building my own for over 10 years. I have tried using the suse kernel but it was too big, and too slow and had behaviors that were too different from the vanilla kernel to be able to report kernel bugs against it.
I'm not sure why you bothered taking part in this discussion then. Apparently you have decided long ago that distribution kernels were not for you. This is your right and I respect that. But whatever my conclusions are at the end of this discussion, you will keep building your custom kernel anyway.
(...) When I see my desktop, it's totally responsive. The unnecessary services are booted in background at low priority. They don't affect foreground services.
They do. "In background at low priority" is a lie as long as you have a single end-user-class, spinning HDD. Even we have experienced that with beagle, tracker etc. in the past. The I/O is the bottleneck and in fact you can hear it. I used to know my Windows system was ready when I stopped hearing the hard disk drive work like crazy. Thankfully SSDs are improving the situation significantly.
That's because you are booting with a initrd.
Yes, we are booting with an initrd. And I am trying to make that happen as fast as possible. I am not discussing whether initrd is good or if it could be avoided or if it could be replaced by something else. If you have an interest in this, feel free to work on it, start your own discussion thread, etc.
Once you've added in that cost, you've hidden most other benefits.. My system would boot from start of unpacking linux to system prompt and all services running in ~25 seconds.
That number says nothing until you compare it with other approaches on the same system. My workstation takes less than 10 seconds from unpacking linux to graphical prompt, with the desktop kernel flavor. That's much faster than yours, all it means is that a SSD, a fast CPU and enough RAM helps a lot for fast booting. It doesn't mean that the openSUSE desktop kernel is intrinsically faster than your custom kernel. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org