You are not logged in.
A small illustration to my proposal to do kernel optimization.
There is a wonderful assembly thread
https://dev1galaxy.org/viewtopic.php?id=564
But our task is a little different, github is not needed.
The algorithm is this:
Install the corresponding package linux -source-xxx. unpack it.
apt-get build-dep linux
Further commands with root rights in the folder /usr/src/linux -source-xxx
make localmodconfig
make menuconfig
Select / remove the necessary / unnecessary
make -j 6
make modules_prepare
make modules_install install
We reboot.
Here is the result without apparmor, TOMOYO and other things without much fanaticism.
Offline
Would it not be better to build a .deb package? Instructions here:
https://www.debian.org/doc/manuals/debi … n-official
And this will use all of the cores for any machine:
# make -j$(nproc)
Brianna Ghey — Rest In Power
Offline
@Head_on_a_Stick
I did not set out to write a complete instruction.
Of course, you can create a package, in the "HOWTO" at the link there is an example of a command.
In general, compiling the kernel is an occupation for a more or less qualified user with his own preferences.
Thanks for the make command tip.
I didn't even think about that.
PS. One caveat - this case requires hard drive space. The initial 4.5 GB was not enough for me, I had to use gparted-live usb.
Last edited by aluma (2022-12-22 18:36:34)
Offline
Would it not be better to build a .deb package?
Unless you're planning to distribute it, and/or are maintaining your own repository and serving the kernel as updates to multiple systems which you administer, there's actually little point to packaging every kernel rebuild as a deb.
If you're maintaining your own kernel for personal use - i.e. doing a git pull, rebuilding and installing, etc, it's far more expedient to just use make.
Last edited by blackhole (2022-12-23 12:24:40)
Offline
there's actually little point to packaging every kernel rebuild as a deb
What about all of the patches Debian apply to their kernel? And why would the kernel be any different to any other software? I wouldn't dream of using plain make install, even if a decent uninstall target is provided in the Makefile. It just seems so... crude to not use the provided packaging tools.
Although having said that Debian's packaging is so ridiculously complicated compared to, for example, Arch or Alpine that I can see why you might want to avoid it :-)
Brianna Ghey — Rest In Power
Offline
blackhole wrote:there's actually little point to packaging every kernel rebuild as a deb
What about all of the patches Debian apply to their kernel? And why would the kernel be any different to any other software? I wouldn't dream of using plain make install, even if a decent uninstall target is provided in the Makefile. It just seems so... crude to not use the provided packaging tools.
Although having said that Debian's packaging is so ridiculously complicated compared to, for example, Arch or Alpine that I can see why you might want to avoid it :-)
Custom kernels are something of a personal nature. Debian provides mostly vanilla built kernels. The same reason i would not deb package a dwm or dmenu binary with my own configs, its much easier to use make, build-essential and tcc. I f i were a package maintainer for devuan or debian it would be a different story.
"A stop job is running..." - SystemD
Offline
I always build my own packages for dwm & dmenu. I even made a live ISO for my custom dwm desktop
Brianna Ghey — Rest In Power
Offline
What about all of the patches
This is the whole intrigue!
Package linux-source - two archives, sources and a patch. Next is your decision.
Here they say that kernel compilation is funny.
Absolutely correct.
For me, in the dialup days, it was a common procedure to get a new release in the form of a set of CDs. By that time, I had already played enough computer games and this activity was no less interesting.
P.S. Regarding make -j .
The question is not in the number of cores, but in the sequence of compilation of various parts. With a large number of tasks, errors are possible when some are compiled before the necessary ones are ready.
In my case with AMD E-300 j=4.
The example in the first post was just copied from "HOWTO" .
Last edited by aluma (2022-12-24 20:33:30)
Offline
Offline
P.S. Regarding make -j .
The question is not in the number of cores, but in the sequence of compilation of various parts. With a large number of tasks, errors are possible when some are compiled before the necessary ones are ready.
Utter nonsense.
Last edited by Head_on_a_Stick (2022-12-28 18:01:54)
Brianna Ghey — Rest In Power
Offline
aluma wrote:P.S. Regarding make -j .
The question is not in the number of cores, but in the sequence of compilation of various parts. With a large number of tasks, errors are possible when some are compiled before the necessary ones are ready.Utter nonsense.
Too lazy to argue and look for links.
Here at hand
"#make
This will build the kernel image you will install later. You can use -jn as a make argument, where n will be the number of CPU cores in your system + 1 in order to enable parallel building which, of course, will speed up the process."
https://linuxconfig.org/in-depth-howto- … figuration
P.S. I would venture to suggest that you check this case practically - compile the kernel with different values of -j . With your computer, this will not take long, unlike in my case.
P.P.S. In any case, the kernel compiled for a specific computer boots and runs faster than the standard one.
Practically, this means that you can use "human" DEs, such as Trinity or XFCE, rather than looking for "minimal" command-line interface-oriented ones.
But programmers have their own opinion, they don't care about users.
Last edited by aluma (2022-12-28 20:54:01)
Offline
The number of "parrots" of the hardifo GPU test
- standard kernel (5.10...., 5.18...) 1547
- custom kernel 1605.
Offline