June 17, 2011 at 20:35Interview with TuxOnIce Developer Nigel Cunningham
The developer of the hibernation subsystem for the Linux kernel, Nigel Cunningham, kindly took the time to answer questions from readers of Habr and ENT.
The interview touches on the development of TuxOnIce and its inclusion in the kernel, as well as Nigel's hobbies and preferences.
Where are you from?
I grew up in Auckland, New Zealand, but I have lived in Australia for the past 14 years. Now I live in Geelong, this is a little south of Melbourne.
Is programming your profession? When did you start doing it? What is your favorite programming language?
In general, about professions I am a minister of the Christian (Protestant) church, but before that I received a bachelor's degree in trade in the field of information systems management and management.
As a child, I was a bit a computer geek, but over time, people became more interested in me than computers. After completing the theological courses about 10 years ago, I was engaged in both IT and Christian ministry. What I am doing now unites these two things. I work at the Theological College of Melbourne, coordinating their distance learning program. As part of this, I am working on an e-learning software called Moodle, and I am also involved in the main Drupal website.
I started programming in my early teens. The first family computer was the Dick Smith VZ-200 (it was sold in Australia and New Zealand), and then I got the Commodore 64, on which I made the first attempt to program. I learned machine code to such an extent that I wrote a small system with a pop-up menu, the code of which was located mostly in RAM, which usually hid 16 Kb of the basic ROM of the C-64 computer.
I'm not sure that I have a favorite programming language. I mainly use two now: C for the kernel and PHP for website development. I like them both, but everything has its place: C is good for kernel programming, and PHP is good for websites. If you change your question, I can say that Scheme I love the least. I had a chance to study it while doing computer science tasks, when I was studying for a bachelor's degree, and I think that all these brackets are more conducive to selling pills for headaches than to readability of the code! :)
Your hobbies?
I like to take care of the plants a little - now for the third time I have been observing how tulips grow from the soil, I really like to look at them.
I am also an active member of the local emergency service - this is a group of volunteers that helps people with floods, storms and other emergency situations. I really liked learning to climb roofs safely, regulate traffic, and the like, so I look forward to taking other necessary courses so that later I can put my acquired skills into practice.
Do you have pets at home (cats are especially interested, most of our readers are obsessed with them)? What are their names? Do they help you program?
I am ashamed to admit that I do not have pets. But there are two kids that I really love. My wife Michelle and I have a 13-year-old son, Elisdair, and a 3-year-old daughter, Irene. Elizder wants to learn how to program, but has not yet learned.
How did the development of suspend2 begin? When did it start? Why was the name “suspend2” and not “suspend”?
Work on hibernation began about 10 years ago, when I seriously started working on Linux. At the theological college, I wanted to run Bible study programs, but they were only for Windows. I had to run Linux first, then Win4Lin, and then Logos (the same Bible study program). It took about five minutes each time. And then I began to look at hibernation as an instrument to speed up the whole process.
Then hibernation was not yet at the core. This was around the time of 2.4.16 and earlier versions of 2.5. Gabor Kuti and Pavel Machek created a very simplified version of the software sleep and called it swsusp. I tried it and subscribed to the swsusp mailing list on Sourceforge. Then he slowly began to learn how it works, and to learn C, and then he began to send small patches to make swsusp faster, more reliable and friendlier. If I remember correctly, Gabor did not have much time for development, so, naturally, I was engaged in development.
Around this time, Paul managed to include code in the 2.5 kernel branch, but (again, if memory serves me right) without consulting the community. I tried to work with Pavel, but nothing worked, and our paths slowly diverged.
As for the name, one thing has always annoyed me - here's how to pronounce it “swsusp” ?! So I just called it “software suspend”. Suddenly we reached the point where it was possible to assign version 1.0 ( in July 2003 ).
Development continued until we released version 2.0 at the end of January 2004. They called her "suspend2". The development of Suspend2 continued, but after 2005 it slowed down significantly, because my priorities changed and the software became more mature. Recently, Rafael Wysocki, who wanted to name the hibernation software as “hibernation” rather than “suspend,” has been lit up. To realize this desire, I proposed a new name, so TuxOnIce appeared by chance. We continued the version numbering, so the current one is 3.2.
Is Linux Power Management Code Good enough? What can be done to improve it?
This code has a long way to go. Much has been done, but much more needs to be done, too, because in order to manage the power well, you need to combine power management on the fly (that is, keep power while using the system) and control system states (falling asleep and / or hibernation ) You need to work with a bunch of different architectures and devices, you need a flexible approach to meet the requirements of different users and different work scenarios. In addition, good power management requires not only a good kernel, but also well-written applications. A better power management system can be crippled by one problem, for example, in a poor event polling cycle.
Therefore, the issue of power management is more than just a small hibernation issue that I am working on. This is really a problem for everyone.
But let me think a little narrower and concentrate on hibernation. Here the answer is the same: no, IMHO, now the code in the kernel is not good enough. I believe that software should be as reliable, flexible, friendly, and careless as possible. The current code has come a long way since the first version adopted in the kernel, but there is still much to be done.
Part of it is my fault. I have not put in enough effort to push the TuxOnIce code into the kernel. A few years ago there was a desire to review the code to include it in the kernel, but I already made too many changes compared to the kernel code. It is impossible for someone to review it well. In addition, I really do not understand what they wanted or demanded of me, so I wasted a lot of time and effort. TuxOnIce has many valuable features that I think should be included in the kernel. But this must be done at a time, so someone who has more time than mine is needed. Well, of course, Linus can bite the bullet and take TuxOnIce as it is. Although I do not believe that such a thing will ever happen.
Therefore, I think that the best that people can do to improve core power management is to get down to business and help. You can try to push TuxOnIce (or its improved version) into the kernel or improve what is already in the kernel. Of course, being a programmer is not necessary - just telling us about problems with individual device drivers is also very useful. None of the kernel developers can test the code on each configuration, therefore, it is impossible to fix unknown bugs. Just tell me if there is a problem, help me find the reason and try the corrected version - this will be a huge help even without writing code.
What can you say about the increased power consumption in the 2.6.38 core ( see this article )?
Alas, I can’t help with anything, I don’t follow all the changes between versions. In general, I can say that with such a regression, anyone can help using the git bisect tool. The main idea is that when testing, for example, kernels 2.6.37 and 2.6.38, we try half the changes between versions and see if there is a problem. If it is, you just need to halve the search between the two versions. This is done several times until, with confidence, you can say: "This patch is the root of evil." Typically, 12-16 iterations of compiling and testing the kernel are sufficient, but it is still much simpler and more accurate than just guessing. In short, google "git bisect", there are good examples.
Some people complain that ACPI in Linux is the cause of many problems. What do you say?
The problem that open source developers have faced from the very beginning of its formation is the interaction with proprietary software, which, moreover, is often poorly written. In the context of the Linux kernel, this means - among other things - interaction with the computer BIOS. BIOS programmers - they, like all programmers, make mistakes, misunderstand the specifications, or even read them somehow differently. Sometimes problems exist in the specifications themselves. And this means that if dudes from Intel write an ACPI implementation for Linux, it will not work if you stupidly follow the specifications. Everywhere they have to play with workarounds. I don’t know ACPI well enough to say that there are no problems in its specification, but from what I’ve heard in recent years, I can say that most of the problems are not related to ACPI,
Is the hibernation code in the vanilla kernel high enough? What are the advantages and disadvantages of using vanilla hibernation?
As I said, I think that much needs to be done to improve it. Its basis is stable and monolithic, the absence of the need to change it is a big advantage. But there are many points that need to be improved. In order not to be unfounded, I’ll name, for example, the speed that can be increased with the help of, among other methods, the introduction of multi-threaded processing and read-ahead. You can also screw on support for regular files (not swapping), which will avoid races in the conditions of running out of memory and increase reliability (and there will no longer be problems with insufficient storage for the picture). Reliability can be improved by first calculating whether there is enough memory and storage capacity to create an atomic copy (usually the amount of memory needed for drivers is quite predictable). And actually the code can be taken out in modules to free up memory to more necessary things at a time when hibernation is not required. Of course, this does not hurt desktop computers, but embedded systems also want to hibernate, especially if it can be done quickly.
Therefore, the vanilla kernel code has come a long way since it was turned on. Now it is much more reliable and friendly. Now for him even BUG_ON () - s are not a standard debugging tool!
Can Linux borrow some power management ideas from other (e.g. BSD) systems?
I have not run BSD for a very long time, but I am sure that there is something to share. This is the powerful power of open source software, especially for such small and lonely developers like me. We do not care about patents or about how to hide our secrets from competitors. We focus more on the quality of the software itself. Therefore, yes, I think that there are ideas that need to be shared so that as a result, users feel better than they were.
What is the purpose of TuxOnIce? Why are you developing it?
TuxOnIce exists to give users the best Linux hibernation they can get. I develop it primarily because I want to use it, and also because there are a bunch of loyal users who make me maintain and improve it. I am more than happy that I can give something to the community. In the end, I've been using free software on my computers for over 10 years - it's fair to give something in return.
Do you prefer to turn off the computer or hibernate it? How often do you turn off your computer completely?
Most of the time I use TuxOnIce. Sometimes it happens that I try swsusp or just turn off the computer, but this is more an exception than a rule.
About a year ago, I bought a laptop SSD. I was struck by the difference in speed. On the old disk, the read and write speed was about 100 Mb / s (50 Mb / s is the disk speed, another half of the speed increase was given by the LZF compression algorithm). When using an SSD, the image is recorded at a speed of about 250 Mb / s, and read at a speed of 380 Mb / s. At these speeds, hibernation with 4 GB of RAM does not take much time, and the advantage is that after waking up, all running programs and open documents appear again as if the computer did not turn off. Well, why then just turn it off? :)
What is the difference between vanilla hibernation and TuxOnIce? Is TuxOnIce better than vanilla hibernation?
These two pieces share a lot of code. They make the same calls to the driver model and follow the same pattern of freezing processes, creating an atomic copy, writing it to disk and turning off the power.
The main difference is that the vanilla kernel performs single-threaded I / O by sending pages in batches, while TuxOnIce is multithreaded and does not use packets. This increases throughput (of course, it all depends on the features of the hardware).
The second significant difference is that TuxOnIce saves the image in two parts. The memory is divided into pages that will not be involved in reading or writing an image (mainly, these are process and LRU pages), and all other pages (you can make sure that the first part of the pages is really not involved by enabling the calculation of the checksum of the pages, which will slightly increase hibernation time). In this mode (it is enabled by default, but it can also be turned off) TuxOnIce first writes unused pages to disk, then creates an atomic copy of the remaining pages, copying them to unused memory, as well as the memory used by the first group of pages. Then this atomic copy is written to disk before shutting down.
On the other hand, swsusp creates an atomic copy of all pages, which means that the maximum size of the image that can be written is 50% of RAM. If you still need to write more than 50%, the algorithm will free up memory until the condition “free 50% of RAM” is satisfied. In fact, it frees even more, since some memory is required for actually recording the image.
The trade-off between freeing up memory and recording an entire image is that writing (and reading) a larger image takes longer, but gives more responsiveness to the system after waking up. Recording a smaller image takes less time, but after waking up, the pages will fail (which is slower, especially on mechanical media, because the search takes time, which is already so long due to failures), and freeing up memory also takes some time.
Historically, TuxOnIce was the first to provide many new features. It first appeared support for SMP, a good user interface, support for the swap file, and now there are such things as checking the time of the last mount, which is not in the vanilla version.
Are there any intentions to include TuxOnIce in the kernel instead of the existing hibernation subsystem? Have you tried to do this?
I would like this to happen, but my shift in priorities in recent years means that it’s hard for me to find the time.
As I mentioned, several times there were ideas to review the code, but in essence this did not happen. So in the future we are waiting for a gradual improvement of the code that is already in the kernel. This is a great and long work, but I see only this way.
If vanilla hibernation works fine, should TuxOnIce be used? Why yes or why not?
If vanilla hibernation works fine, use it. If something doesn't suit you, don't be afraid to try TuxOnIce. More importantly, keep in touch with the developers, tell them what needs to be improved and why. We cannot fix problems if we do not know about their existence.
How many developers besides you work on TuxOnIce?
Over the years, Bernard Blackham associates have provided me with tremendous and invaluable help. Bernard developed a user interface in the user space that is still in use. Others tested TuxOnIce a lot and sent great reports. But the kernel patch has always been my brainchild. Many people sent patches, but the design, development, support and documentation are mine.
Do you commit to the vanilla core? What subsystems are you interested in besides power management?
From time to time, I make commits to hibernation subsystems, for example, to the memory manager, but this does not happen very often. I became a kernel hacker just because I wanted to see improvements in the code I use every day.
If users encounter bugs in TuxOnIce, what should they do to improve its quality? How to collect debugging information if TuxOnIce crashes once a month?
The main thing in finding bugs is to get information about where the problem occurred. The ideal situation, if it is possible to highlight the problem line and the problem configuration. To do this, you need a kernel with debugging information. When oops occurs (if it relates to a bug), write down the address and use the addr2line utility after rebooting to find the line on which everything crashed.
Context is also important, so you should get the addresses of 4–5 functions from the call chain and also convert them to file names and line numbers.
This will give an idea of what code led to oops.
Another part of the picture is a description of the computer configuration. This includes the kernel configuration file, which should be attached to the bug report (there is a kernel compilation option that puts the configuration file in /proc/config.gz, I highly recommend including it!). You should also describe where the image was saved (file? Swap partition? Swap file?). Finally, the output of the dmesg command can generally be priceless.
It is best if possible to use netconsole and the TuxOnIce interactive debugger to get a more detailed picture of what led to the problem. Netconsole can be useful for capturing backtrace of all processes.
Other useful tools are kdb (especially with KMS!) And a digital camera (it’s better to take a picture of the screen than to record all the details manually - just select a shooting resolution at which the information remains readable and the file size is small).
Which distribution do you use? What is your favorite work environment?
I am a Ubuntu user, mainly because, in general, everything just works here. As a working environment, xfce4 is used, but with the AWN panel.
Do you support the inclusion of such things as BFS, BFQ, reiser4 in the kernel? Do you think Linus’s position on this is well-balanced?
As an answer to the second question, I admit that I have no idea what Linus thinks about it. Unlike most people in the kernel community, I’m somehow outside - I don’t have a programming career (although I sometimes want it to be that way), and I am primarily a user who wants fast, reliable and frequent hibernation! Right now, I'm not even subscribed to the kernel mailing list. In fact, I am reading only one list that is not related to TuxOnIce - on power management, and that’s not all!
And now to the first question.
Some problems are difficult to solve, different approaches are of different quality. In addition, different users have different priorities in what they are looking for. This applies to both schedulers and file systems, so I sincerely support the idea of providing different options for control options in the kernel, allowing the user to choose. This is one of the principles implemented in TuxOnIce. If you look in / sys / power / tuxonice, you can see a lot of options to configure for your needs, because one boot will not fit all.
What do you think of kernel version numbering ?
We have been discussing 3.0 for many years, I am glad that the time has finally come. Of course, I would like to see more changes in the kernel itself. And I would also like the kernel to have version 3.0.0. Why complicate life?
Have you encountered bug # 12309 ? What can you say about this?
Oh yes, every time a virtual machine falls asleep in VMware. I do not want to comment on this, because I know that problems with planners are difficult to solve. What I like about TuxOnIce is that if you freeze everything else, there aren't many problems with the scheduler!
Which kernel developer do you personally know?
Well, I met some of them in recent years at the kernel summit and at Linux.Conf.Au conferences , but I don’t know any of them well enough. This is all due to the fact that I do not work in Red Hat, Intel, Ubuntu or something like that.
I had the pleasure of visiting Canberra 7 years ago and working a bit with Rusty Russel and some of the guys who were at IBM, but there was nothing serious and lengthy.
Which open source development team is best organized and made up of professionals?
I only worked with the Drupal community (about 4 years), but I am impressed with how they do what they should.
What other open source projects have you participated in?
I participated in the development of many Drupal modules (Mailfix and Fasttoggle, as well as, to a lesser extent, the OG Mailing list) and recently started supporting fork of the pam-mysql module on Github.
Are you ready for IPv6?
Not. I am not well versed in IPv6, but in the future you will need to do something if the addresses run out. Nevertheless, I will learn only what will be necessary for this thing to work. You can't know everything, Google is your friend! :)
What is your best achievement in life?
Um. Hard question. I don’t think much about achievements or about the fact that they need to be proud of. I think it should be said that I am satisfied with what TuxOnIce is - it is quite stable and mature (although problems with drivers and changes in the vanilla kernel mean that there is always work). I am also happy that I have a positive influence in the family, church and society. In the end, I think it is better to serve than to serve, and if there is an opportunity to look back and look at the life in which I did so, then I will be happy.
Thanks for answers!
Yes please. Thank you for your questions!
The original interview is here .
The interview touches on the development of TuxOnIce and its inclusion in the kernel, as well as Nigel's hobbies and preferences.
Where are you from?
I grew up in Auckland, New Zealand, but I have lived in Australia for the past 14 years. Now I live in Geelong, this is a little south of Melbourne.
Is programming your profession? When did you start doing it? What is your favorite programming language?
In general, about professions I am a minister of the Christian (Protestant) church, but before that I received a bachelor's degree in trade in the field of information systems management and management.
As a child, I was a bit a computer geek, but over time, people became more interested in me than computers. After completing the theological courses about 10 years ago, I was engaged in both IT and Christian ministry. What I am doing now unites these two things. I work at the Theological College of Melbourne, coordinating their distance learning program. As part of this, I am working on an e-learning software called Moodle, and I am also involved in the main Drupal website.
I started programming in my early teens. The first family computer was the Dick Smith VZ-200 (it was sold in Australia and New Zealand), and then I got the Commodore 64, on which I made the first attempt to program. I learned machine code to such an extent that I wrote a small system with a pop-up menu, the code of which was located mostly in RAM, which usually hid 16 Kb of the basic ROM of the C-64 computer.
I'm not sure that I have a favorite programming language. I mainly use two now: C for the kernel and PHP for website development. I like them both, but everything has its place: C is good for kernel programming, and PHP is good for websites. If you change your question, I can say that Scheme I love the least. I had a chance to study it while doing computer science tasks, when I was studying for a bachelor's degree, and I think that all these brackets are more conducive to selling pills for headaches than to readability of the code! :)
Your hobbies?
I like to take care of the plants a little - now for the third time I have been observing how tulips grow from the soil, I really like to look at them.
I am also an active member of the local emergency service - this is a group of volunteers that helps people with floods, storms and other emergency situations. I really liked learning to climb roofs safely, regulate traffic, and the like, so I look forward to taking other necessary courses so that later I can put my acquired skills into practice.
Do you have pets at home (cats are especially interested, most of our readers are obsessed with them)? What are their names? Do they help you program?
I am ashamed to admit that I do not have pets. But there are two kids that I really love. My wife Michelle and I have a 13-year-old son, Elisdair, and a 3-year-old daughter, Irene. Elizder wants to learn how to program, but has not yet learned.
How did the development of suspend2 begin? When did it start? Why was the name “suspend2” and not “suspend”?
Work on hibernation began about 10 years ago, when I seriously started working on Linux. At the theological college, I wanted to run Bible study programs, but they were only for Windows. I had to run Linux first, then Win4Lin, and then Logos (the same Bible study program). It took about five minutes each time. And then I began to look at hibernation as an instrument to speed up the whole process.
Then hibernation was not yet at the core. This was around the time of 2.4.16 and earlier versions of 2.5. Gabor Kuti and Pavel Machek created a very simplified version of the software sleep and called it swsusp. I tried it and subscribed to the swsusp mailing list on Sourceforge. Then he slowly began to learn how it works, and to learn C, and then he began to send small patches to make swsusp faster, more reliable and friendlier. If I remember correctly, Gabor did not have much time for development, so, naturally, I was engaged in development.
Around this time, Paul managed to include code in the 2.5 kernel branch, but (again, if memory serves me right) without consulting the community. I tried to work with Pavel, but nothing worked, and our paths slowly diverged.
As for the name, one thing has always annoyed me - here's how to pronounce it “swsusp” ?! So I just called it “software suspend”. Suddenly we reached the point where it was possible to assign version 1.0 ( in July 2003 ).
Development continued until we released version 2.0 at the end of January 2004. They called her "suspend2". The development of Suspend2 continued, but after 2005 it slowed down significantly, because my priorities changed and the software became more mature. Recently, Rafael Wysocki, who wanted to name the hibernation software as “hibernation” rather than “suspend,” has been lit up. To realize this desire, I proposed a new name, so TuxOnIce appeared by chance. We continued the version numbering, so the current one is 3.2.
Is Linux Power Management Code Good enough? What can be done to improve it?
This code has a long way to go. Much has been done, but much more needs to be done, too, because in order to manage the power well, you need to combine power management on the fly (that is, keep power while using the system) and control system states (falling asleep and / or hibernation ) You need to work with a bunch of different architectures and devices, you need a flexible approach to meet the requirements of different users and different work scenarios. In addition, good power management requires not only a good kernel, but also well-written applications. A better power management system can be crippled by one problem, for example, in a poor event polling cycle.
Therefore, the issue of power management is more than just a small hibernation issue that I am working on. This is really a problem for everyone.
But let me think a little narrower and concentrate on hibernation. Here the answer is the same: no, IMHO, now the code in the kernel is not good enough. I believe that software should be as reliable, flexible, friendly, and careless as possible. The current code has come a long way since the first version adopted in the kernel, but there is still much to be done.
Part of it is my fault. I have not put in enough effort to push the TuxOnIce code into the kernel. A few years ago there was a desire to review the code to include it in the kernel, but I already made too many changes compared to the kernel code. It is impossible for someone to review it well. In addition, I really do not understand what they wanted or demanded of me, so I wasted a lot of time and effort. TuxOnIce has many valuable features that I think should be included in the kernel. But this must be done at a time, so someone who has more time than mine is needed. Well, of course, Linus can bite the bullet and take TuxOnIce as it is. Although I do not believe that such a thing will ever happen.
Therefore, I think that the best that people can do to improve core power management is to get down to business and help. You can try to push TuxOnIce (or its improved version) into the kernel or improve what is already in the kernel. Of course, being a programmer is not necessary - just telling us about problems with individual device drivers is also very useful. None of the kernel developers can test the code on each configuration, therefore, it is impossible to fix unknown bugs. Just tell me if there is a problem, help me find the reason and try the corrected version - this will be a huge help even without writing code.
What can you say about the increased power consumption in the 2.6.38 core ( see this article )?
Alas, I can’t help with anything, I don’t follow all the changes between versions. In general, I can say that with such a regression, anyone can help using the git bisect tool. The main idea is that when testing, for example, kernels 2.6.37 and 2.6.38, we try half the changes between versions and see if there is a problem. If it is, you just need to halve the search between the two versions. This is done several times until, with confidence, you can say: "This patch is the root of evil." Typically, 12-16 iterations of compiling and testing the kernel are sufficient, but it is still much simpler and more accurate than just guessing. In short, google "git bisect", there are good examples.
Some people complain that ACPI in Linux is the cause of many problems. What do you say?
The problem that open source developers have faced from the very beginning of its formation is the interaction with proprietary software, which, moreover, is often poorly written. In the context of the Linux kernel, this means - among other things - interaction with the computer BIOS. BIOS programmers - they, like all programmers, make mistakes, misunderstand the specifications, or even read them somehow differently. Sometimes problems exist in the specifications themselves. And this means that if dudes from Intel write an ACPI implementation for Linux, it will not work if you stupidly follow the specifications. Everywhere they have to play with workarounds. I don’t know ACPI well enough to say that there are no problems in its specification, but from what I’ve heard in recent years, I can say that most of the problems are not related to ACPI,
Is the hibernation code in the vanilla kernel high enough? What are the advantages and disadvantages of using vanilla hibernation?
As I said, I think that much needs to be done to improve it. Its basis is stable and monolithic, the absence of the need to change it is a big advantage. But there are many points that need to be improved. In order not to be unfounded, I’ll name, for example, the speed that can be increased with the help of, among other methods, the introduction of multi-threaded processing and read-ahead. You can also screw on support for regular files (not swapping), which will avoid races in the conditions of running out of memory and increase reliability (and there will no longer be problems with insufficient storage for the picture). Reliability can be improved by first calculating whether there is enough memory and storage capacity to create an atomic copy (usually the amount of memory needed for drivers is quite predictable). And actually the code can be taken out in modules to free up memory to more necessary things at a time when hibernation is not required. Of course, this does not hurt desktop computers, but embedded systems also want to hibernate, especially if it can be done quickly.
Therefore, the vanilla kernel code has come a long way since it was turned on. Now it is much more reliable and friendly. Now for him even BUG_ON () - s are not a standard debugging tool!
Can Linux borrow some power management ideas from other (e.g. BSD) systems?
I have not run BSD for a very long time, but I am sure that there is something to share. This is the powerful power of open source software, especially for such small and lonely developers like me. We do not care about patents or about how to hide our secrets from competitors. We focus more on the quality of the software itself. Therefore, yes, I think that there are ideas that need to be shared so that as a result, users feel better than they were.
What is the purpose of TuxOnIce? Why are you developing it?
TuxOnIce exists to give users the best Linux hibernation they can get. I develop it primarily because I want to use it, and also because there are a bunch of loyal users who make me maintain and improve it. I am more than happy that I can give something to the community. In the end, I've been using free software on my computers for over 10 years - it's fair to give something in return.
Do you prefer to turn off the computer or hibernate it? How often do you turn off your computer completely?
Most of the time I use TuxOnIce. Sometimes it happens that I try swsusp or just turn off the computer, but this is more an exception than a rule.
About a year ago, I bought a laptop SSD. I was struck by the difference in speed. On the old disk, the read and write speed was about 100 Mb / s (50 Mb / s is the disk speed, another half of the speed increase was given by the LZF compression algorithm). When using an SSD, the image is recorded at a speed of about 250 Mb / s, and read at a speed of 380 Mb / s. At these speeds, hibernation with 4 GB of RAM does not take much time, and the advantage is that after waking up, all running programs and open documents appear again as if the computer did not turn off. Well, why then just turn it off? :)
What is the difference between vanilla hibernation and TuxOnIce? Is TuxOnIce better than vanilla hibernation?
These two pieces share a lot of code. They make the same calls to the driver model and follow the same pattern of freezing processes, creating an atomic copy, writing it to disk and turning off the power.
The main difference is that the vanilla kernel performs single-threaded I / O by sending pages in batches, while TuxOnIce is multithreaded and does not use packets. This increases throughput (of course, it all depends on the features of the hardware).
The second significant difference is that TuxOnIce saves the image in two parts. The memory is divided into pages that will not be involved in reading or writing an image (mainly, these are process and LRU pages), and all other pages (you can make sure that the first part of the pages is really not involved by enabling the calculation of the checksum of the pages, which will slightly increase hibernation time). In this mode (it is enabled by default, but it can also be turned off) TuxOnIce first writes unused pages to disk, then creates an atomic copy of the remaining pages, copying them to unused memory, as well as the memory used by the first group of pages. Then this atomic copy is written to disk before shutting down.
On the other hand, swsusp creates an atomic copy of all pages, which means that the maximum size of the image that can be written is 50% of RAM. If you still need to write more than 50%, the algorithm will free up memory until the condition “free 50% of RAM” is satisfied. In fact, it frees even more, since some memory is required for actually recording the image.
The trade-off between freeing up memory and recording an entire image is that writing (and reading) a larger image takes longer, but gives more responsiveness to the system after waking up. Recording a smaller image takes less time, but after waking up, the pages will fail (which is slower, especially on mechanical media, because the search takes time, which is already so long due to failures), and freeing up memory also takes some time.
Historically, TuxOnIce was the first to provide many new features. It first appeared support for SMP, a good user interface, support for the swap file, and now there are such things as checking the time of the last mount, which is not in the vanilla version.
Are there any intentions to include TuxOnIce in the kernel instead of the existing hibernation subsystem? Have you tried to do this?
I would like this to happen, but my shift in priorities in recent years means that it’s hard for me to find the time.
As I mentioned, several times there were ideas to review the code, but in essence this did not happen. So in the future we are waiting for a gradual improvement of the code that is already in the kernel. This is a great and long work, but I see only this way.
If vanilla hibernation works fine, should TuxOnIce be used? Why yes or why not?
If vanilla hibernation works fine, use it. If something doesn't suit you, don't be afraid to try TuxOnIce. More importantly, keep in touch with the developers, tell them what needs to be improved and why. We cannot fix problems if we do not know about their existence.
How many developers besides you work on TuxOnIce?
Over the years, Bernard Blackham associates have provided me with tremendous and invaluable help. Bernard developed a user interface in the user space that is still in use. Others tested TuxOnIce a lot and sent great reports. But the kernel patch has always been my brainchild. Many people sent patches, but the design, development, support and documentation are mine.
Do you commit to the vanilla core? What subsystems are you interested in besides power management?
From time to time, I make commits to hibernation subsystems, for example, to the memory manager, but this does not happen very often. I became a kernel hacker just because I wanted to see improvements in the code I use every day.
If users encounter bugs in TuxOnIce, what should they do to improve its quality? How to collect debugging information if TuxOnIce crashes once a month?
The main thing in finding bugs is to get information about where the problem occurred. The ideal situation, if it is possible to highlight the problem line and the problem configuration. To do this, you need a kernel with debugging information. When oops occurs (if it relates to a bug), write down the address and use the addr2line utility after rebooting to find the line on which everything crashed.
Context is also important, so you should get the addresses of 4–5 functions from the call chain and also convert them to file names and line numbers.
This will give an idea of what code led to oops.
Another part of the picture is a description of the computer configuration. This includes the kernel configuration file, which should be attached to the bug report (there is a kernel compilation option that puts the configuration file in /proc/config.gz, I highly recommend including it!). You should also describe where the image was saved (file? Swap partition? Swap file?). Finally, the output of the dmesg command can generally be priceless.
It is best if possible to use netconsole and the TuxOnIce interactive debugger to get a more detailed picture of what led to the problem. Netconsole can be useful for capturing backtrace of all processes.
Other useful tools are kdb (especially with KMS!) And a digital camera (it’s better to take a picture of the screen than to record all the details manually - just select a shooting resolution at which the information remains readable and the file size is small).
Which distribution do you use? What is your favorite work environment?
I am a Ubuntu user, mainly because, in general, everything just works here. As a working environment, xfce4 is used, but with the AWN panel.
Do you support the inclusion of such things as BFS, BFQ, reiser4 in the kernel? Do you think Linus’s position on this is well-balanced?
As an answer to the second question, I admit that I have no idea what Linus thinks about it. Unlike most people in the kernel community, I’m somehow outside - I don’t have a programming career (although I sometimes want it to be that way), and I am primarily a user who wants fast, reliable and frequent hibernation! Right now, I'm not even subscribed to the kernel mailing list. In fact, I am reading only one list that is not related to TuxOnIce - on power management, and that’s not all!
And now to the first question.
Some problems are difficult to solve, different approaches are of different quality. In addition, different users have different priorities in what they are looking for. This applies to both schedulers and file systems, so I sincerely support the idea of providing different options for control options in the kernel, allowing the user to choose. This is one of the principles implemented in TuxOnIce. If you look in / sys / power / tuxonice, you can see a lot of options to configure for your needs, because one boot will not fit all.
What do you think of kernel version numbering ?
We have been discussing 3.0 for many years, I am glad that the time has finally come. Of course, I would like to see more changes in the kernel itself. And I would also like the kernel to have version 3.0.0. Why complicate life?
Have you encountered bug # 12309 ? What can you say about this?
Oh yes, every time a virtual machine falls asleep in VMware. I do not want to comment on this, because I know that problems with planners are difficult to solve. What I like about TuxOnIce is that if you freeze everything else, there aren't many problems with the scheduler!
Which kernel developer do you personally know?
Well, I met some of them in recent years at the kernel summit and at Linux.Conf.Au conferences , but I don’t know any of them well enough. This is all due to the fact that I do not work in Red Hat, Intel, Ubuntu or something like that.
I had the pleasure of visiting Canberra 7 years ago and working a bit with Rusty Russel and some of the guys who were at IBM, but there was nothing serious and lengthy.
Which open source development team is best organized and made up of professionals?
I only worked with the Drupal community (about 4 years), but I am impressed with how they do what they should.
What other open source projects have you participated in?
I participated in the development of many Drupal modules (Mailfix and Fasttoggle, as well as, to a lesser extent, the OG Mailing list) and recently started supporting fork of the pam-mysql module on Github.
Are you ready for IPv6?
Not. I am not well versed in IPv6, but in the future you will need to do something if the addresses run out. Nevertheless, I will learn only what will be necessary for this thing to work. You can't know everything, Google is your friend! :)
What is your best achievement in life?
Um. Hard question. I don’t think much about achievements or about the fact that they need to be proud of. I think it should be said that I am satisfied with what TuxOnIce is - it is quite stable and mature (although problems with drivers and changes in the vanilla kernel mean that there is always work). I am also happy that I have a positive influence in the family, church and society. In the end, I think it is better to serve than to serve, and if there is an opportunity to look back and look at the life in which I did so, then I will be happy.
Thanks for answers!
Yes please. Thank you for your questions!
The original interview is here .
