Interview with Nigel Cunningham, TuxOnIce developer
The developer of the hibernation subsystem for the Linux kernel, Nigel Cunningham, has kindly devoted time to answering questions from readers of Habr and LOR.
The interview touches upon the topic of developing TuxOnIce and including it in the core, 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, it's a little south of Melbourne.
')
Is programming your profession? When did you start practicing it? What is your favorite programming language?
In general, about the profession I am a minister of the Christian (Protestant) church, but before that I received a bachelor's degree in commerce in the field of information systems management and management.
As a child, I was a bit of a computer geek, but over time I became more interested in people than computers. After finishing theological courses about 10 years ago, I was engaged in IT and Christian ministry. What I do now unites these two things. I work at the Melbourne Theological College, coordinating their distance learning program. As part of this, I’m working on e-learning software called Moodle, as well as the main Drupal website.
I started programming in my early teens. The first family computer was 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 the 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 was usually hidden in 16 KB of the basic ROM of the C-64 computer.
I'm not sure that I have a favorite programming language. Basically, I use two now: C for the kernel and PHP for developing the website. I both like them, 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 I like the Scheme the least. I happened to study it while performing computer science tasks when I was studying for a bachelor’s degree, and I think that all these brackets are more conducive to the sale of headache tablets than readability of the code! :)
What are your hobbies?
I like to take care of the plants a little - now for the third time I am watching how tulips grow from the soil, I really love to look at them.
I am also an active member of the local emergency service — a group of volunteers that helps people with floods, storms, and other emergency situations. I really liked learning how to climb roofs safely, regulate traffic and the like, so I look forward to taking other necessary courses so that I can apply the acquired skills in practice.
Do you have pets at home (cats are particularly interested, most of our readers are obsessed with them)? What are their names? Do they help you to program?
I am ashamed to admit, I have no pets. But there are two kids who I love very much. My wife and I, Michelle, have 13-year-old son Elizder (Alisdair) and 3-year-old daughter Irene (Irene). Elizder wants to learn how to program, but has not yet learned.
How did suspend2 development begin? When it started? Why was the name “suspend2” instead of “suspend”?
The work on hibernation began about 10 years ago, when I seriously started working on Linux. In a theological college, I wanted to run a Bible study program, but they were only for Windows. I had to run Linux first, then Win4Lin, and then Logos (the same Bible study program). It took every five minutes. And then I began to look at hibernation as an instrument for the acceleration of the whole process.
Then the hibernation was not yet in the core. This was around the time of 2.4.16 and earlier versions of branch 2.5. Gabor Kuti and Pavel Machek created a very simplified version of software sleep and called it swsusp. I tried it and subscribed to the swsusp mailing list on Sourceforge. Then he slowly began to study how it works, and learn C, and then began to send small patches to make swsusp faster, more reliable and friendlier. If I remember correctly, Gabor didn’t have much time for development, so naturally, I was engaged in development.
At about this time, Pavel achieved the inclusion of code in the 2.5 kernel branch, but (again, if memory serves me) without consulting the community. I tried to work with Pavel, but nothing worked, and our paths slowly diverged.
As for the name, one thing always annoyed me - is this how to pronounce this “swsusp” ?! Therefore, I called it simply “software suspend”. Suddenly we reached the point where version 1.0 could be assigned ( in July 2003 ).
Development continued until we released version 2.0 at the end of January 2004. They called it "suspend2". Suspend2 development continued, but after 2005 it slowed down significantly because my priorities changed and the software became more mature. Recently, Raphael Wysocki (Rafael Wysocki), who wanted to call the software for hibernation as "hibernation", rather than "suspend", has appeared. To translate this desire, I proposed a new name, so by chance TuxOnIce appeared. We continued the version numbering, so the current one is 3.2.
Is the power management code in Linux good enough? What can be done to improve it?
This code has a long way to go. Much has been done, but there is still a lot to be done, because in order to manage the power well, you need to combine power management “on the fly” (i.e., maintain power while using the system) and managing system states (sleep 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 mutilated by one problem, for example, in a bad event polling cycle.
Therefore, the issue of power management is more than just a small hibernation issue that I work on. This is really a problem of all.
But let me think a little bit already 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 as seamless as possible. The current code has come a long way since the first version adopted in the core, but there is still a lot to be done.
This is partly my fault. I haven't put enough effort into pushing the TuxOnIce code into the kernel. A few years ago, there was a desire to review the code for inclusion in the kernel, but I already made too many changes in comparison with the nuclear 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 it needs to be done at once, so you need someone who has more time than me. Well, of course, Linus can bite the bullet and take TuxOnIce as it is. Although I do not believe that such a thing ever happens.
Therefore, I think that the best that people can do to improve power management in the core is to get down to business and help. You can try to push into the core TuxOnIce (or its improved version), or to improve what is already in the core. Of course, it is not necessary to be a programmer - just tell us about problems with individual device drivers - this 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 cause and try the corrected version - it will be a huge help even without writing code.
What can you say about the increased power consumption in the 2.6.38 kernel ( see this article )?
Alas, I can not help you, I do not 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 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 double the search area between the two versions. This is done several times until, with certainty, we can say: "This patch is the root of evil." Usually, 12–16 iterations of compiling and testing the kernel are sufficient, but it is still much simpler and more accurate than simple 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 faced by open-source software developers from the very beginning of its formation is interaction with closed-source 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, misinterpret specifications, or even read them in a different way. Sometimes there are problems in the specifications themselves. And this means that if the guys with Intel write the ACPI implementation for Linux, it will not work if you stupidly follow the specifications. They everywhere will have to play with workarounds. I don’t know ACPI well enough to say that there are no problems with its specification, but from what I’ve heard in recent years, I can say that most of the problems are not related to ACPI, but to different ACPI BIOSes and tables, which the BIOS developers wrote.
Is the hibernation code in the vanilla core sufficiently qualitative? What are the advantages and disadvantages of using vanilla hibernation?
As I said, I think a lot needs to be done to improve it. Its basis is stable and monolithic, the absence of the need to change it is a great advantage. But there are many points that need to be improved. In order not to be unfounded, for example, I call the speed, which can be increased with the help of - in addition to other methods - the introduction of multi-threaded processing and read ahead. You can also tighten the support for regular files (not swapping), which will allow you to avoid racing in conditions of low memory and increase reliability (and there will be no more problems with insufficient storage size for a snapshot). Reliability can be improved if you first carry out calculations as to whether there is enough memory and storage capacity for creating an atomic copy (usually the amount of memory needed for drivers is predictable). And the actual code can be transferred to modules in order to free up memory for more necessary things at a time when hibernation is not required. Of course, this doesn’t hurt desktops, but embedded systems also want to hibernate, especially if this can be done quickly.
Therefore, the vanilla kernel code has come a long way since it was included. Now he is much safer and friendlier. Now even BUG_ON () for it are not standard debugging tools!
Can Linux borrow some power management ideas from other (eg, BSD) systems?
I haven't run BSD for a long time, but I am sure that there is something to share. This is a powerful force in open source software, especially for such small and lonely developers like me. We do not care about patents or 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 become 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 lot of dedicated users who make me support and improve it. I am more than happy to give something to the community. In the end, I have been using free software on my computers for over 10 years - it’s honest to give something in return.
Do you prefer to turn off the computer or hibernate it? How often do you turn off the 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 the exception rather than the rule.
About a year ago I bought an SSD for a laptop. 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 — the disk speed, another half of the speed increase was given by the LZF compression algorithm). When using SSD-disk image is recorded at a speed of about 250 MB / s, and read at a speed of 380 MB / s. At such speeds, hibernation with 4 GB of RAM does not take much time, and the advantage is that after waking up all the running programs and open documents appear again like the computer did not turn off. Well, why is it even then just turn off? :)
What is the difference between vanilla hibernation and TuxOnIce? 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 process freeze pattern, creating an atomic copy, writing it to disk and turning off the power.
The main difference is that the vanilla core performs single-threaded I / O, sending pages to packets, while TuxOnIce is multi-threaded and does not use packets. This increases throughput (of course, everything also 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 used when reading or writing an image (basically, these are process pages and LRU), and all other pages (you can make sure that the first part of the pages is really not involved by turning on the page checksum calculation, which slightly increases hibernation time). In this mode (it is enabled by default, but it can be turned off) TuxOnIce first writes unused pages to disk, then creates an atomic copy of the remaining pages, copying them into 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. This approach allows you to record a full image of memory (the first group of pages usually significantly exceeds 50% of RAM in size).
On the other hand, swsusp creates an atomic copy of all pages, which means that the maximum image size that can be written is 50% of the 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 also required for the actual recording of the image.
The trade-off between freeing the memory and recording the whole image is that writing (and reading) the larger image takes more time, but gives more responsiveness of the system after waking up. Writing a smaller image takes less time, but after waking up, a failure will occur in the pages (which is slower, especially on mechanical media, because the search takes time, which is already long due to failures), and it also takes some time to free the memory.
Historically, TuxOnIce was the first to provide a large number of new features. It first appeared support for SMP, a good user interface, support for the paging 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 this?
I would like this to happen, but my shift in priorities in recent years means that it’s hard for me to find time for it.
As I already 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 long and hard work, but I see only this way.
If vanilla hibernation works fine, should I use TuxOnIce? Why or why not?
If vanilla hibernation works fine, use it. If something does not suit you, do not be afraid to try TuxOnIce. More importantly, keep in touch with the developers, tell them what needs to be improved and why. We can not fix the problems if we do not know about their existence.
How many developers other than you are working on TuxOnIce?
Over the years, Bernard Blackham (Bernard Blackham) associates have given me tremendous and invaluable help. Bernard has developed a user-space user interface that is still in use. Others have tested TuxOnIce a lot and sent great reports. But the core patch has always been my brainchild. Many who sent patches, but the design, development, support and documentation is mine.
Do you commit commits to the vanilla core? What subsystems are you interested in other than power management?
, , , , . , , .
TuxOnIce, , ? , TuxOnIce ?
— , . , . . oops ( ), addr2line , .
, 4–5 .
, oops'.
— . , ( , /proc/config.gz, - !). , (? ? ?). , dmesg .
netconsole TuxOnIce, , . Netconsole .
— kdb ( KMS!) ( , — , , ).
? ?
— Ubuntu, , , , . xfce4, AWN.
, BFS, BFQ, reiser4? ?
, , . , - – ( , ), , , ! . , , TuxOnIce — , !
.
, -. , , . , , , . , TuxOnIce. /sys/power/tuxonice, , .
?
3.0 , , - . , . , 3.0.0. ?
â„–12309 ? ?
, VMware. , , . TuxOnIce, , , !
?
Linux.Conf.Au , . - , Red Hat, Intel, Ubuntu - .
7 (Rusty Russel) , IBM, .
?
Drupal ( 4 ), , , .
?
Drupal (Mailfix Fasttoggle, OG Mailing list) pam-mysql Github.
IPv6?
Not. IPv6, - , . , , , . , Google — ! :)
?
Um Hard question. , . , , , TuxOnIce — ( , ). , , . , , , , , , .
!
. !
.
The interview touches upon the topic of developing TuxOnIce and including it in the core, 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, it's a little south of Melbourne.
')
Is programming your profession? When did you start practicing it? What is your favorite programming language?
In general, about the profession I am a minister of the Christian (Protestant) church, but before that I received a bachelor's degree in commerce in the field of information systems management and management.
As a child, I was a bit of a computer geek, but over time I became more interested in people than computers. After finishing theological courses about 10 years ago, I was engaged in IT and Christian ministry. What I do now unites these two things. I work at the Melbourne Theological College, coordinating their distance learning program. As part of this, I’m working on e-learning software called Moodle, as well as the main Drupal website.
I started programming in my early teens. The first family computer was 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 the 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 was usually hidden in 16 KB of the basic ROM of the C-64 computer.
I'm not sure that I have a favorite programming language. Basically, I use two now: C for the kernel and PHP for developing the website. I both like them, 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 I like the Scheme the least. I happened to study it while performing computer science tasks when I was studying for a bachelor’s degree, and I think that all these brackets are more conducive to the sale of headache tablets than readability of the code! :)
What are your hobbies?
I like to take care of the plants a little - now for the third time I am watching how tulips grow from the soil, I really love to look at them.
I am also an active member of the local emergency service — a group of volunteers that helps people with floods, storms, and other emergency situations. I really liked learning how to climb roofs safely, regulate traffic and the like, so I look forward to taking other necessary courses so that I can apply the acquired skills in practice.
Do you have pets at home (cats are particularly interested, most of our readers are obsessed with them)? What are their names? Do they help you to program?
I am ashamed to admit, I have no pets. But there are two kids who I love very much. My wife and I, Michelle, have 13-year-old son Elizder (Alisdair) and 3-year-old daughter Irene (Irene). Elizder wants to learn how to program, but has not yet learned.
How did suspend2 development begin? When it started? Why was the name “suspend2” instead of “suspend”?
The work on hibernation began about 10 years ago, when I seriously started working on Linux. In a theological college, I wanted to run a Bible study program, but they were only for Windows. I had to run Linux first, then Win4Lin, and then Logos (the same Bible study program). It took every five minutes. And then I began to look at hibernation as an instrument for the acceleration of the whole process.
Then the hibernation was not yet in the core. This was around the time of 2.4.16 and earlier versions of branch 2.5. Gabor Kuti and Pavel Machek created a very simplified version of software sleep and called it swsusp. I tried it and subscribed to the swsusp mailing list on Sourceforge. Then he slowly began to study how it works, and learn C, and then began to send small patches to make swsusp faster, more reliable and friendlier. If I remember correctly, Gabor didn’t have much time for development, so naturally, I was engaged in development.
At about this time, Pavel achieved the inclusion of code in the 2.5 kernel branch, but (again, if memory serves me) without consulting the community. I tried to work with Pavel, but nothing worked, and our paths slowly diverged.
As for the name, one thing always annoyed me - is this how to pronounce this “swsusp” ?! Therefore, I called it simply “software suspend”. Suddenly we reached the point where version 1.0 could be assigned ( in July 2003 ).
Development continued until we released version 2.0 at the end of January 2004. They called it "suspend2". Suspend2 development continued, but after 2005 it slowed down significantly because my priorities changed and the software became more mature. Recently, Raphael Wysocki (Rafael Wysocki), who wanted to call the software for hibernation as "hibernation", rather than "suspend", has appeared. To translate this desire, I proposed a new name, so by chance TuxOnIce appeared. We continued the version numbering, so the current one is 3.2.
Is the power management code in Linux good enough? What can be done to improve it?
This code has a long way to go. Much has been done, but there is still a lot to be done, because in order to manage the power well, you need to combine power management “on the fly” (i.e., maintain power while using the system) and managing system states (sleep 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 mutilated by one problem, for example, in a bad event polling cycle.
Therefore, the issue of power management is more than just a small hibernation issue that I work on. This is really a problem of all.
But let me think a little bit already 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 as seamless as possible. The current code has come a long way since the first version adopted in the core, but there is still a lot to be done.
This is partly my fault. I haven't put enough effort into pushing the TuxOnIce code into the kernel. A few years ago, there was a desire to review the code for inclusion in the kernel, but I already made too many changes in comparison with the nuclear 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 it needs to be done at once, so you need someone who has more time than me. Well, of course, Linus can bite the bullet and take TuxOnIce as it is. Although I do not believe that such a thing ever happens.
Therefore, I think that the best that people can do to improve power management in the core is to get down to business and help. You can try to push into the core TuxOnIce (or its improved version), or to improve what is already in the core. Of course, it is not necessary to be a programmer - just tell us about problems with individual device drivers - this 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 cause and try the corrected version - it will be a huge help even without writing code.
What can you say about the increased power consumption in the 2.6.38 kernel ( see this article )?
Alas, I can not help you, I do not 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 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 double the search area between the two versions. This is done several times until, with certainty, we can say: "This patch is the root of evil." Usually, 12–16 iterations of compiling and testing the kernel are sufficient, but it is still much simpler and more accurate than simple 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 faced by open-source software developers from the very beginning of its formation is interaction with closed-source 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, misinterpret specifications, or even read them in a different way. Sometimes there are problems in the specifications themselves. And this means that if the guys with Intel write the ACPI implementation for Linux, it will not work if you stupidly follow the specifications. They everywhere will have to play with workarounds. I don’t know ACPI well enough to say that there are no problems with its specification, but from what I’ve heard in recent years, I can say that most of the problems are not related to ACPI, but to different ACPI BIOSes and tables, which the BIOS developers wrote.
Is the hibernation code in the vanilla core sufficiently qualitative? What are the advantages and disadvantages of using vanilla hibernation?
As I said, I think a lot needs to be done to improve it. Its basis is stable and monolithic, the absence of the need to change it is a great advantage. But there are many points that need to be improved. In order not to be unfounded, for example, I call the speed, which can be increased with the help of - in addition to other methods - the introduction of multi-threaded processing and read ahead. You can also tighten the support for regular files (not swapping), which will allow you to avoid racing in conditions of low memory and increase reliability (and there will be no more problems with insufficient storage size for a snapshot). Reliability can be improved if you first carry out calculations as to whether there is enough memory and storage capacity for creating an atomic copy (usually the amount of memory needed for drivers is predictable). And the actual code can be transferred to modules in order to free up memory for more necessary things at a time when hibernation is not required. Of course, this doesn’t hurt desktops, but embedded systems also want to hibernate, especially if this can be done quickly.
Therefore, the vanilla kernel code has come a long way since it was included. Now he is much safer and friendlier. Now even BUG_ON () for it are not standard debugging tools!
Can Linux borrow some power management ideas from other (eg, BSD) systems?
I haven't run BSD for a long time, but I am sure that there is something to share. This is a powerful force in open source software, especially for such small and lonely developers like me. We do not care about patents or 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 become 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 lot of dedicated users who make me support and improve it. I am more than happy to give something to the community. In the end, I have been using free software on my computers for over 10 years - it’s honest to give something in return.
Do you prefer to turn off the computer or hibernate it? How often do you turn off the 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 the exception rather than the rule.
About a year ago I bought an SSD for a laptop. 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 — the disk speed, another half of the speed increase was given by the LZF compression algorithm). When using SSD-disk image is recorded at a speed of about 250 MB / s, and read at a speed of 380 MB / s. At such speeds, hibernation with 4 GB of RAM does not take much time, and the advantage is that after waking up all the running programs and open documents appear again like the computer did not turn off. Well, why is it even then just turn off? :)
What is the difference between vanilla hibernation and TuxOnIce? 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 process freeze pattern, creating an atomic copy, writing it to disk and turning off the power.
The main difference is that the vanilla core performs single-threaded I / O, sending pages to packets, while TuxOnIce is multi-threaded and does not use packets. This increases throughput (of course, everything also 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 used when reading or writing an image (basically, these are process pages and LRU), and all other pages (you can make sure that the first part of the pages is really not involved by turning on the page checksum calculation, which slightly increases hibernation time). In this mode (it is enabled by default, but it can be turned off) TuxOnIce first writes unused pages to disk, then creates an atomic copy of the remaining pages, copying them into 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. This approach allows you to record a full image of memory (the first group of pages usually significantly exceeds 50% of RAM in size).
On the other hand, swsusp creates an atomic copy of all pages, which means that the maximum image size that can be written is 50% of the 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 also required for the actual recording of the image.
The trade-off between freeing the memory and recording the whole image is that writing (and reading) the larger image takes more time, but gives more responsiveness of the system after waking up. Writing a smaller image takes less time, but after waking up, a failure will occur in the pages (which is slower, especially on mechanical media, because the search takes time, which is already long due to failures), and it also takes some time to free the memory.
Historically, TuxOnIce was the first to provide a large number of new features. It first appeared support for SMP, a good user interface, support for the paging 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 this?
I would like this to happen, but my shift in priorities in recent years means that it’s hard for me to find time for it.
As I already 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 long and hard work, but I see only this way.
If vanilla hibernation works fine, should I use TuxOnIce? Why or why not?
If vanilla hibernation works fine, use it. If something does not suit you, do not be afraid to try TuxOnIce. More importantly, keep in touch with the developers, tell them what needs to be improved and why. We can not fix the problems if we do not know about their existence.
How many developers other than you are working on TuxOnIce?
Over the years, Bernard Blackham (Bernard Blackham) associates have given me tremendous and invaluable help. Bernard has developed a user-space user interface that is still in use. Others have tested TuxOnIce a lot and sent great reports. But the core patch has always been my brainchild. Many who sent patches, but the design, development, support and documentation is mine.
Do you commit commits to the vanilla core? What subsystems are you interested in other than power management?
, , , , . , , .
TuxOnIce, , ? , TuxOnIce ?
— , . , . . oops ( ), addr2line , .
, 4–5 .
, oops'.
— . , ( , /proc/config.gz, - !). , (? ? ?). , dmesg .
netconsole TuxOnIce, , . Netconsole .
— kdb ( KMS!) ( , — , , ).
? ?
— Ubuntu, , , , . xfce4, AWN.
, BFS, BFQ, reiser4? ?
, , . , - – ( , ), , , ! . , , TuxOnIce — , !
.
, -. , , . , , , . , TuxOnIce. /sys/power/tuxonice, , .
?
3.0 , , - . , . , 3.0.0. ?
â„–12309 ? ?
, VMware. , , . TuxOnIce, , , !
?
Linux.Conf.Au , . - , Red Hat, Intel, Ubuntu - .
7 (Rusty Russel) , IBM, .
?
Drupal ( 4 ), , , .
?
Drupal (Mailfix Fasttoggle, OG Mailing list) pam-mysql Github.
IPv6?
Not. IPv6, - , . , , , . , Google — ! :)
?
Um Hard question. , . , , , TuxOnIce — ( , ). , , . , , , , , , .
!
. !
.
Source: https://habr.com/ru/post/122101/
All Articles