1.介紹Linux休眠提供了一種類似于Windows的休眠方式，使用戶能夠通過休眠操作，保存系統當前的內存數據到硬盤，即s w a p分區中。當計算機重新啟動后，系統重新裝載保存的內存數據，包括進程數據，寄存器數值等，并恢復到關機前的狀態。由于不需要重新裝載文檔，應用程序也不用重新打開，因此休眠啟動方式要比正常的啟動過程快得多。

2.Linux休眠原理要實現操作系統的休眠，首先要理解linux的內存管理機制。標準L i n u x的分頁是三級頁表結構：頁目錄、中間頁目錄和頁。i 3 8 6采用的是兩級頁表結構：頁目錄和頁，不支持中間頁目錄。4 G的線性地址空間，只有一個頁目錄，它最多有1024個目錄項，每個目錄項又含有1024個頁面項，每個頁面有4 K字節。分頁機制通過把線性地址空間中的頁，重新定位到物理地址空間來進行管理，因為每個頁面的整個4K字節作為一個單位進行映射，并且每個頁面都對齊4K字節的邊界，因此，線性地址的低12位經過分頁機制直接地作為物理地址的低1 2位使用。下圖所示是x86下線性地址映射為物理地址的過程：休眠過程可以分為兩個階段,一是SUSPEND階段,二是R E S U M E階段, R E S U M E過程是S U S P E N D的逆過程。S U S P E N D階段保存進程數據到硬盤中,并關機;RESUME階段,從硬盤中讀取保存的進程數據,并恢復到關機前的原始狀態。休眠需要解決的問題中,最重要的部分是內存數據的保存和如何恢復保存的內存數據。我們可以很容易獲取內存頁面數據,SUSPEND的過程中,主要任務就是要保存這些需要保存的頁面,但是,作為存儲頁面地址的頁表也需要保存下來，因為頁表僅僅是一個中間轉換作用的鏈表,所以，可以在S U S P E N D的過程中,臨時建立,然后將內存頁面地址記錄在頁表中。RESUME的階段,將保存的頁面和頁表寫到內存頁中，完成后,只要重新修改頁目錄數據,就完成內存數據還原動作了。經過以上分析，可以得到休眠的大體原理圖，如下所示：如圖所示,實現S U S P E N D需要完成三個主要步驟：凍結系統中的活動進程,準備保存內存數據,寫內存數據到硬盤。凍結活動進程：包括三類主要的活動源，即，用戶空間進程和內核線程，設備驅動和活動的計時器；準備保存數據：計算需要保存的內存頁數，分配內存以保存進程數據，復制進程數據到分配的內存中；保存數據到硬盤：寫需要保存的內存頁到硬盤中。RESUME是SUSPEND的逆過程，要完成分配內存以讀取硬盤中的進程數據，讀取硬盤數據，重新映射頁表地址，更新段描述符表等。

3 Linux軟件休眠實現休眠以模塊方式實現，用戶可以根據自己的需要選擇是否裝載此模塊。但是，因為休眠在R E S U M E的過程中，需要恢復關機前的內存數據，以及c p u狀態等，所以，此模塊的裝載應該通過ramdisk的init自動裝載，并且要在mount root文件系統之前。

3.1 SUSPEND階段3.1.1凍結活動進程進程執行時，它會根據具體情況改變狀態。Linux中的進程狀態主要有以下幾種：T A S K _ R U N N I N G可運行T

A S K _ I N T E R R U P T I B L E可中斷的等待狀態T A S K _ U N I N T E

R R U P T I B L E不可中斷的等待狀態T A S K _ Z O M B I E僵死T A S K _ S T O P P E D暫停T A S K _ S W A P P I N G換入/換出操作系統在運行過程中，一般有十幾個，甚至幾十個進程在運行。S U S P E N D進程獲得執行的資源而執行，即當前進程(current)，是不能被凍結和中止執行，否則后續的操作會得不到完全執行；另外，進程標志為P F _ N O F R E E E Z

E和P F _ F R O Z E N的；以及進程狀態為T A S K _ Z O M B I E、T A S K _ D E A D、T A S K _ S T O P P E

D，這些進程是不能凍結的或者不需要凍結的。除此之外，其余的進程需要凍結，也就是改變進程標志為P F _ F R E E Z E。進程標志改為P F _ F R E E Z E后，相應的進程會因為獲不到資源，從而處于靜止狀態。3.1.2準備保存數據檢測所有內存頁，如果頁面標識不是PG_reserved，則需要保存的頁面數加1。內存檢測完成后，得到需要保存的頁面數目，即nr_copy_pages。for (pfn = 0; pfn < max_pfn; pfn++){page =

pfn_to_page(pfn);if (!PageReserved(page)){….nr_copy_pages ++….}…由nr_copy_pages數目，得到內存中對應數目的空閑頁面作為頁表目錄數，同時分配nr_copy_pages個空閑頁，頁地址由頁表目錄記錄管理。除了進程數據外，當前寄存器的數據，包括描述符表，段寄存器，控制寄存器，以及通用寄存器的值，都作為全局變量保存下來。復制需要保存的內存頁面到新分配的空閑頁中。for (pfn = 0; pfn

< max_pfn; pfn++) {….if (pagedir_p) {pagedir_p->orig_address

=ADDRESS(pfn);copy_page((void *) pagedir_p->address,(void *) pagedir_p->orig_address);pagedir_p++;}….}3.1.3保存數據到swap分區

摘要:休眠操作通過保存當前系統進程數據和cpu狀態數據到硬盤中，當系統斷電并重新啟動后，又自動讀取保存的數據并恢復到原始系統狀態，如此大大減少了系統的啟動時間。內存管理，進程管理和swap操作等方面是休眠實現的主要涉及范圍，因此對于深入理解linux操作系統有所幫助。

關鍵詞:Linux;內核;休眠; swap__

Freezing of tasks

(C) 2007 Rafael J. Wysocki <>, GPL

I. What is the freezing of tasks?

The freezing of tasks is a mechanism by

which user space processes and some

kernel threads are controlled during hibernation or system-wide suspend (on

some

architectures).

II. How does it work?

There are four per-task flags used for

that, PF_NOFREEZE, PF_FROZEN, TIF_FREEZE

and PF_FREEZER_SKIP (the last one is auxiliary).? The tasks that have

PF_NOFREEZE unset (all user space processes and some kernel threads) are

regarded as 'freezable' and treated in a special way before the system enters a

suspend state as well as before a hibernation image is created (in what follows

we only consider hibernation, but the description also applies to suspend).

Namely, as the first step of the

hibernation procedure the function

freeze_processes() (defined in kernel/power/process.c) is called.? It

executes

try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and

either wakes them up, if they are kernel threads, or sends fake signals to

them,

if they are user space processes.? A task that has TIF_FREEZE set, should

react

to it by calling the function called refrigerator() (defined in

kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its

state

to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.

Then, we say that the task is 'frozen' and therefore the set of functions

handling this mechanism is referred to as 'the freezer' (these functions are

defined in kernel/power/process.c and include/linux/freezer.h).? User

space

processes are generally frozen before kernel threads.

It is not recommended to call

refrigerator() directly.? Instead, it is

recommended to use the try_to_freeze() function (defined in

include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the

task enter refrigerator() if the flag is set.

For user space processes try_to_freeze()

is called automatically from the

signal-handling code, but the freezable kernel threads need to call it

explicitly in suitable places or use the wait_event_freezable() or

wait_event_freezable_timeout() macros (defined in include/linux/freezer.h)

that combine interruptible sleep with checking if TIF_FREEZE is set and calling

try_to_freeze().? The main loop of a freezable kernel thread may look like

the

following one:

set_freezable();

do {

hub_events();

wait_event_freezable(khubd_wait,

!list_empty(&hub_event_list) ||

kthread_should_stop());

} while (!kthread_should_stop() || !list_empty(&hub_event_list));

(from

drivers/usb/core/hub.c::hub_thread()).

If a freezable kernel thread fails to call

try_to_freeze() after the freezer has

set TIF_FREEZE for it, the freezing of tasks will fail and the entire

hibernation operation will be cancelled.? For this reason, freezable

kernel

threads must call try_to_freeze() somewhere or use one of the

wait_event_freezable() and wait_event_freezable_timeout() macros.

After the system memory state has been

restored from a hibernation image and

devices have been reinitialized, the function thaw_processes() is called in

order to clear the PF_FROZEN flag for each frozen task.? Then, the tasks

that

have been frozen leave refrigerator() and continue running.

III. Which kernel threads are freezable?

Kernel threads are not freezable by

default.? However, a kernel thread may clear

PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE

directly is strongly discouraged).? From this point it is regarded as

freezable

and must call try_to_freeze() in a suitable place.

IV. Why do we do that?

Generally speaking, there is a couple of

reasons to use the freezing of tasks:

1. The principal reason is to prevent

filesystems from being damaged after

hibernation.? At the moment we have no simple means of checkpointing

filesystems, so if there are any modifications made to filesystem data and/or

metadata on disks, we cannot bring them back to the state from before the

modifications.? At the same time each hibernation image contains some

filesystem-related information that must be consistent with the state of the

on-disk data and metadata after the system memory state has been restored from

the image (otherwise the filesystems will be damaged in a nasty way, usually

making them almost impossible to repair).? We therefore freeze tasks that

might

cause the on-disk filesystems' data and metadata to be modified after the

hibernation image has been created and before the system is finally powered

off.

The majority of these are user space processes, but if any of the kernel

threads

may cause something like this to happen, they have to be freezable.

2. Next, to create the hibernation image

we need to free a sufficient amount of

memory (approximately 50% of available RAM) and we need to do that before

devices are deactivated, because we generally need them for swapping out.

Then,

after the memory for the image has been freed, we don't want tasks to allocate

additional memory and we prevent them from doing that by freezing them earlier.

[Of course, this also means that device drivers should not allocate substantial

amounts of memory from their .suspend() callbacks before hibernation, but this

is e separate issue.]

3. The third reason is to prevent user

space processes and some kernel threads

from interfering with the suspending and resuming of devices.? A user

space

process running on a second CPU while we are suspending devices may, for

example, be troublesome and without the freezing of tasks we would need some

safeguards against race conditions that might occur in such a case.

Although Linus Torvalds doesn't like the

freezing of tasks, he said this in one

of the discussions on LKML ():

"RJW:> Why we freeze tasks at all

or why we freeze kernel threads?

Linus: In many ways, 'at all'.

I _do_ realize the IO request queue

issues, and that we cannot actually do

s2ram with some devices in the middle of a DMA.? So we want to be able to

avoid *that*, there's no question about that.? And I suspect that stopping

user threads and then waiting for a sync is practically one of the easier

ways to do so.

So in practice, the 'at all' may become a

'why freeze kernel threads?' and

freezing user threads I don't find really objectionable."

Still, there are kernel threads that may

want to be freezable.? For example, if

a kernel that belongs to a device driver accesses the device directly, it in

principle needs to know when the device is suspended, so that it doesn't try to

access it at that time.? However, if the kernel thread is freezable, it

will be

frozen before the driver's .suspend() callback is executed and it will be

thawed after the driver's .resume() callback has run, so it won't be accessing

the device while it's suspended.

4. Another reason for freezing tasks is to

prevent user space processes from

realizing that hibernation (or suspend) operation takes place.? Ideally,

user

space processes should not notice that such a system-wide operation has

occurred

and should continue running without any problems after the restore (or resume

from suspend).? Unfortunately, in the most general case this is quite

difficult

to achieve without the freezing of tasks.? Consider, for example, a

process

that depends on all CPUs being online while it's running.? Since we need

to

disable nonboot CPUs during the hibernation, if this process is not frozen, it

may notice that the number of CPUs has changed and may start to work

incorrectly

because of that.

V. Are there any problems related to the

freezing of tasks?

Yes, there are.

First of all, the freezing of kernel

threads may be tricky if they depend one

on another.? For example, if kernel thread A waits for a completion (in

the

TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B

and B is frozen in the meantime, then A will be blocked until B is thawed,

which

may be undesirable.? That's why kernel threads are not freezable by

default.

Second, there are the following two

problems related to the freezing of user

space processes:

1. Putting processes into an uninterruptible sleep distorts the load average.

2. Now that we have FUSE, plus the framework for doing device drivers in

userspace, it gets even more complicated because some userspace processes are

now doing the sorts of things that kernel threads do

().

The problem 1. seems to be fixable,

although it hasn't been fixed so far.? The

other one is more serious, but it seems that we can work around it by using

hibernation (and suspend) notifiers (in that case, though, we won't be able to

avoid the realization by the user space processes that the hibernation is

taking

place).

There are also problems that the freezing

of tasks tends to expose, although

they are not directly related to it.? For example, if request_firmware()

is

called from a device driver's .resume() routine, it will timeout and eventually

fail, because the user land process that should respond to the request is

frozen

at this point.? So, seemingly, the failure is due to the freezing of

tasks.

Suppose, however, that the firmware file is located on a filesystem accessible

only through another device that hasn't been resumed yet.? In that case,

request_firmware() will fail regardless of whether or not the freezing of tasks

is used.? Consequently, the problem is not really related to the freezing

of

tasks, since it generally exists anyway.

A driver must have all firmwares it may

need in RAM before suspend() is called.

If keeping them is not practical, for example due to their size, they must be

requested early enough using the suspend notifier API described in notifiers.txt.

總結

以上是生活随笔為你收集整理的linux关机suspending,（转）Linux 休眠原理与实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。