【IT168技术】IT168移动频道在之前的技术文章中曾经介绍过Android对Linux内核的改动，本文将重点介绍Android对Linux内核的增强，主要包括Alarm(硬件时钟)、Ashmem(匿名内存共享)、Low Memory Killer(低内存管理)、Logger(日志设备)，等等，让大家全方位了解为何Android能将Linux内核在移动领域运用的如此精湛，可以和苹果相抗衡。
Alarm(硬件时钟)
Alarm就是一个硬件时钟，前面我们已经知道它提供了一个定时器，用于把设备从睡眠状态唤醒，同时它也提供了一个在设备睡眠时仍然会运行的时钟基准。在应用层上，有关时间的应用都需要Alarm的支持，源代码位于“drivers/rtc/alarm.c”。
Alarm的设备名为“/dev/alarm”。该设备的实现非常简单，我们首先打开源码，可以看到include ，其中定义了一些Alarm的相关信息。Alarm的类型枚举如下：
enum android_alarm_type {
ANDROID_ALARM_RTC_WAKEUP,
ANDROID_ALARM_RTC,
ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP,
ANDROID_ALARM_ELAPSED_REALTIME,
ANDROID_ALARM_SYSTEMTIME,
ANDROID_ALARM_TYPE_COUNT,
};
主要包括了5种类型的Alarm，_WAKEUP类型表示在触发Alarm时需要唤醒设备，反之则不需要唤醒设备;ANDROID_ALARM_RTC类型表示在指定的某一时刻出发Alarm;ANDROID_ALARM_ELAPSED_REALTIME表示在设备启动后，流逝的时间达到总时间之后触发Alarm;ANDROID_ALARM_SYSTEMTIME类型则表示系统时间;ANDROID_ALARM_ TYPE_COUNT则是Alram类型的计数。
注意 流逝的时间也包括设备睡眠的时间，流逝时间的计算点从它最后一次启动算起。
Alarm返回标记的枚举类型如下：
enum android_alarm_return_flags {
ANDROID_ALARM_RTC_WAKEUP_MASK=1U<
ANDROID_ALARM_RTC_MASK=1U<
ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP_MASK=1U<
ANDROID_ALARM_ELAPSED_REALTIME_MASK=1U<
ANDROID_ALARM_SYSTEMTIME_MASK=1U<
ANDROID_ALARM_TIME_CHANGE_MASK=1U<<16};
Alarm返回标记会随着Alarm的类型而改变。最后还定义了一些宏，主要包括禁用Alarm、Alarm等待、设置Alarm等。下面我们来分析Alarm驱动的具体实现。
首先，Alarm的初始化及退出由以下三个函数来完成：
late_initcall(alarm_late_init);
module_init(alarm_init);
module_exit(alarm_exit);
其中alarm_init函数对Alarm执行初始化操作，alarm_late_init需要在初始化完成之后进行调用，最后退出时需要调用alarm_exit来销毁和卸载Alarm接口及驱动。
1.alarm_init
在初始化过程中，首先需要初始化系统时间，通过platform_driver_register函数来注册Alarm驱动的相关参数，具体如下所示：
static struct platform_driver alarm_driver={
.suspend=alarm_suspend,
.resume=alarm_resume,
.driver={
.name="alarm"}
};
该参数主要指定了当系统挂起(suspend)和唤醒(Desume)所需要实现的分别为alarm_suspend和alarm_resume，同时将Alarm设备驱动的名称设置为了“alarm”。
如果设置正确，那么继续通过如下代码来初始化SUSPEND lock，因为在使用它们之前必须执行初始化操作。
wake_lock_init(&alarm_wake_lock, WAKE_LOCK_SUSPEND, "alarm");
wake_lock_init(&alarm_rtc_wake_lock, WAKE_LOCK_SUSPEND, "alarm_rtc");
紧接着通过class_interface_register函数来注册Alarm接口信息，主要包括设备的添加和移除操作，内容如下：
static struct class_interface rtc_alarm_interface={
.add_dev=&rtc_alarm_add_device,
.remove_dev=&rtc_alarm_remove_device,
};
如果在此过程中出现错误，那么需要销毁已经注册的SUSPEND lock，并且卸载Alarm驱动，代码如下：
wake_lock_destroy(&alarm_rtc_wake_lock);
wake_lock_destroy(&alarm_wake_lock);
platform_driver_unregister(&alarm_driver);
注意 wake lock是一种锁机制，只要有用户持有该锁，系统就无法进入休眠状态，该锁可以被用户态程序和内核获得。这个锁可以是超时的或者是没有超时的，超时的锁会在时间过期以后自动解锁。如果没有锁或者超时了，内核就会启动休眠机制进入休眠状态，后面在讲电源管理时还会进一步讲解该机制。
2.alarm_late_init
当Alarm启动之后，我们需要读取当前的RCT和系统时间，由于需要确保在这个操作过程中不被中断，或者在中断之后能告诉其他进程该过程没有读取完成，不能被请求，因此这里需要通过spin_lock_irqsave和spin_unlock_irqrestore来对其执行锁定和解锁操作。实现代码如下：
staticint__init alarm_late_init(void)
{
unsignedlongflags;
struct timespec system_time;
spin_lock_irqsave(&alarm_slock, flags);
getnstimeofday(&elapsed_rtc_delta);
ktime_get_ts(&system_time);
elapsed_rtc_delta=timespec_sub(elapsed_rtc_delta, system_time);
spin_unlock_irqrestore(&alarm_slock, flags);
ANDROID_ALARM_DPRINTF(ANDROID_ALARM_PRINT_INFO,"alarm_late_init: rtc to elapsed realtime delta %ld.%09ld\n",
elapsed_rtc_delta.tv_sec, elapsed_rtc_delta.tv_nsec);
return0;
}
3.alarm_exit
当Alarm退出时，就需要通过class_interface_unregister函数来卸载在初始化时注册的Alarm接口，通过wake_lock_destroy函数来销毁SUSPEND lock，以及通过platform_driver_unregister函数来卸载Alarm驱动。实现代码如下：
static void __exit alarm_exit(void)
{
class_interface_unregister(&rtc_alarm_interface);
wake_lock_destroy(&alarm_rtc_wake_lock);
wake_lock_destroy(&alarm_wake_lock);
platform_driver_unregister(&alarm_driver);
}
4.添加和移除设备
接下来是rtc_alarm_add_device和rtc_alarm_remove_device函数的实现。添加设备时，首先将设备转换成rtc_device类型，然后，通过misc_register函数将自己注册成为一个Misc设备。其包括的主要特性如下面的代码所示：
static struct file_operations alarm_fops={
.owner=THIS_MODULE,
.unlocked_ioctl=alarm_ioctl,
.open=alarm_open,
.release=alarm_release,
};
static struct miscdevice alarm_device={
.minor=MISC_DYNAMIC_MINOR,
.name="alarm",
.fops=&alarm_fops,
};
其中alarm_device中的“.name”表示设备文件名称，而alarm_fops则定义了Alarm的常用操作，包括打开、释放和I/O控制。这里还需要通过rtc_irq_register函数注册一个rtc_task，用来处理Alarm触发的方法，其定义如下：
static struct rtc_task alarm_rtc_task={
.func=alarm_triggered_func
};
其中“alarm_triggered_func”则是Alarm需要触发的方法。
注意 如果在添加设备的过程中出现错误，我们需要对已经执行的操作进行释放、销毁和卸载。但是，移除一个设备时同样需要判断设备是否是Alarm设备，然后再执行卸载等操作。另外，在处理挂起操作时，我们首先就需要对设备进行锁定，然后根据Alarm的类型执行不同的操作，同时要保存时间。
alarm_open和alarm_release的实现很简单。最后需要说明的是，对于I/O操作而言，主要需要实现：设置时间、设置RTC、获取时间、设置Alarm等待等。
本小节主要对Android中最简单的设备驱动——Alarm的实现流程进行了分析，大家应该可以自己绘制出一个流程图来了吧。对于Alarm的具体实现，大家可以参考源代码“drivers/rtc/alarm.c”中的实现方式。
Ashmem(匿名内存共享)
Ashmem是Android的内存分配与共享机制，它在dev目录下对应的设备文件为/dev/ashmem，其实现的源文件为：
include/linux/ashmem.h
kernel/mm/ashmem.c
相比于malloc和anonymous/named mmap等传统的内存分配机制，其优势是通过内核驱动提供了辅助内核的内存回收算法机制(pin/unpin)。什么是pin和unpin呢?具体来讲，就是当你使用Ashmem分配了一块内存，但是其中某些部分却不会被使用时，那么就可以将这块内存unpin掉。unpin后，内核可以将它对应的物理页面回收，以作他用。你也不用担心进程无法对unpin掉的内存进行再次访问，因为回收后的内存还可以再次被获得(通过缺页handler)，因为unpin操作并不会改变已经 mmap的地址空间。下面就来分析Ashmem的内核驱动是如何完成这些功能。
首先，打开其头文件(ashmem.h)，可以看到定义了以下一些宏和结构体：
//设备文件名称
#define ASHMEM_NAME_DEF"dev/ashmem"//从ASHMEM_PIN返回的值，判断是否需要清楚
#define ASHMEM_NOT_PURGED0#define ASHMEM_WAS_PURGED1//从ASHMEM_GET_PIN_STATUS返回的值，判断是pin还是unpin
#define ASHMEM_IS_UNPINNED0#define ASHMEM_IS_PINNED1struct ashmem_pin {
__u32 offset;//在Ashmem区域的偏移量
__u32len;//从偏移量开始的长度
};
另外一些宏用于设置Ashmem的名称和状态，以及pin和unpin等操作。接下来看一下Ashmem的具体实现，打开(ashmem.c)文件，首先大致预览一下它有哪些功能函数，如图2-1所示。
▲图2-1 Ashmem实现函数列表
可以看到Ashmem是通过以下代码来管理其初始化和退出操作的，我们分别需要实现其初始化函数ashmem_init和退出函数ashmem_exit。
module_init(ashmem_init);
module_exit(ashmem_exit);
ashmem_init的实现很简单，首先，定义一个结构体ashmem_area代表匿名共享内存区;然后，定义一个结构体ashmem_range代表unpinned页面的区域，代码如下：
struct ashmem_area {
char name[ASHMEM_FULL_NAME_LEN];struct list_head unpinned_list;struct file*file;size_t size;unsignedlongprot_mask;};
struct ashmem_range {
struct list_head lru;struct list_head unpinned;struct ashmem_area*asma;size_t pgstart;size_t pgend;unsignedintpurged;};
ashmem_area的生命周期为文件的open()和release()操作之间，而ashmem_range的生命周期则是从unpin到pin，初始化时首先通过kmem_cache_create创建一个高速缓存cache，所需参数如下：
name 用于/proc/slabinfo文件中来识别这个cache
size 在对应的cache中所创建的对象的长度
align 对象对齐尺寸
flags SLAB标志
ctor 构造函数
如果创建成功，则返回指向cache的指针;如果创建失败，则返回NULL。当针对cache的新的页面分配成功时运行ctor构造函数，然后采用unlikely来对其创建结果进行判断。如果成功，就接着创建ashmem_range的cache(实现原理与ashmem_area一样)。创建完成之后，通过misc_register函数将Ashmem注册为misc设备。这里需要注意，我们对所创建的这些cache都需要进行回收，因此，再紧接着需调用register_shrinker注册回收函数ashmem_shrinker。而从图2-1可以看出，ashmem_shrinker实际上是一个结构体，真正的回收函数是在ashmem_shrinker中定义的ashmem_shrink。到这里，初始化操作则完成了，实现代码如下：
staticint__init ashmem_init(void)
{intret;
ashmem_area_cachep=kmem_cache_create("ashmem_area_cache",
sizeof(struct ashmem_area),0,0,NULL);if(unlikely(!ashmem_area_cachep)) {
printk(KERN_ERR"ashmem: failed to create slab cache\n");
return-ENOMEM;
}
ashmem_range_cachep=kmem_cache_create("ashmem_range_cache",
sizeof(struct ashmem_range),0,0,NULL);if(unlikely(!ashmem_range_cachep)) {
printk(KERN_ERR"ashmem: failed to create slab cache\n");
return-ENOMEM;
}
ret=misc_register(&ashmem_misc);if(unlikely(ret)) {
printk(KERN_ERR"ashmem: failed to register misc device!\n");
return ret;
}register_shrinker(&ashmem_shrinker);
printk(KERN_INFO"ashmem: initialized\n");
return0;
}
当Ashmem退出时，又该执行什么操作呢?下面是Ashmem退出时需要执行的ashmem_exit函数的具体实现：
static void __exit ashmem_exit(void)
{intret;unregister_shrinker(&ashmem_shrinker);ret=misc_deregister(&ashmem_misc);if(unlikely(ret))
printk(KERN_ERR"ashmem: failed to unregister misc device!\n");kmem_cache_destroy(ashmem_range_cachep);
kmem_cache_destroy(ashmem_area_cachep);
printk(KERN_INFO"ashmem: unloaded\n");
}
现在我们已经很清楚Ashmem的初始化和退出操作了，接下来我们将分析使用Ashmem对内存进行分配、释放和回收等机制的实现过程。在了解这些实现之前，我们先看看Ashmem分配内存的流程：
1)打开“/dev/ashmem”文件。
2)通过ioctl来设置名称和尺寸等。
3)调用mmap将Ashmem分配的空间映射到进程空间。
由于Ashmem支持pin/unpin机制，所以还可以通过ioctl来pin和unpin某一段映射的空间。Ashmem的作用就是分配空间，打开多少次/dev/ashmem设备并mmap，就会获得多少个不同的空间。
下面来分析如何通过打开设备文件来分配空间，并对空间进行回收。我们在初始化Ashmem时注册了Ashmem设备，其中包含的相关方法及其作用如下面的代码所示。
static struct file_operations ashmem_fops={
.owner=THIS_MODULE,
.open=ashmem_open,.release=ashmem_release,.mmap=ashmem_mmap,.unlocked_ioctl=ashmem_ioctl,.compat_ioctl=ashmem_ioctl,
};
static struct miscdevice ashmem_misc={
.minor=MISC_DYNAMIC_MINOR,
.name="ashmem",
.fops=&ashmem_fops,
};
其中，ashmem_open方法主要是对unpinned列表进行初始化，并将Ashmem分配的地址空间赋给file结构的private_data，这就排除了进程间共享的可能性。ashmem_release方法用于将指定的节点的空间从链表中删除并释放掉。需要指出的是，当使用list_for_each_entry_safe(pos, n, head,member)函数时，需要调用者另外提供一个与pos同类型的指针n，在for循环中暂存pos节点的下一个节点的地址，避免因pos节点被释放而造成断链。ashmem_release函数的实现如下：
staticintashmem_release(struct inode*ignored, struct file*file)
{
struct ashmem_area*asma=file->private_data;
struct ashmem_range*range,*next;
mutex_lock(&ashmem_mutex);
list_for_each_entry_safe(range,next,&asma->unpinned_list, unpinned)
range_del(range);mutex_unlock(&ashmem_mutex);if(asma->file)
fput(asma->file);
kmem_cache_free(ashmem_area_cachep, asma);
return0;
}
接下来就是将分配的空间映射到进程空间。在ashmem_mmap函数中需要指出的是，它借助了Linux内核的shmem_file_setup(支撑文件)工具，使得我们不需要自己去实现这一复杂的过程。所以ashmem_mmap的整个实现过程很简单，大家可以参考它的源代码。最后，我们还将分析通过ioctl来pin和unpin某一段映射的空间的实现方式。ashmem_ioctl函数的功能很多，它可以通过其参数cmd来处理不同的操作，包括设置(获取)名称和尺寸、pin/unpin以及获取pin的一些状态。最终对pin/unpin的处理会通过下面这个函数来完成：
//pin/unpin处理函数
static int ashmem_pin_unpin(struct ashmem_area *asma, unsigned long cmd,void __user *p)
//如果页面是unpinned和ASHMEM_IS_PINNED,则返回ASHMEM_IS_UNPINNED状态
static int ashmem_get_pin_status(struct ashmem_area *asma, size_t pgstart,size_t pgend)
//unpin 指定区域页面，返回0表示成功
//调用者必须持有ashmem_mutex
static int ashmem_unpin(struct ashmem_area *asma, size_t pgstart, size_t pgend)
//pin ashmem指定的区域
//返回是否曾被清除过(即ASHMEM_WAS_PURGED或者ASHMEM_NOT_PURGED)
//调用者必须持有ashmem_mutex
static int ashmem_pin(struct ashmem_area *asma, size_t pgstart, size_t pgend)
最后需要说明：回收函数cache_shrinker同样也参考了Linux内核的slab分配算法用于页面回收的回调函数。具体实现如下：
staticintashmem_shrink(intnr_to_scan, gfp_t gfp_mask)
{
struct ashmem_range*range,*next;if(nr_to_scan&&!(gfp_mask&__GFP_FS))
return-1;if(!nr_to_scan)
return lru_count;
mutex_lock(&ashmem_mutex);
list_for_each_entry_safe(range,next,&ashmem_lru_list, lru) {
struct inode*inode=range->asma->file->f_dentry->d_inode;
loff_t start=range->pgstart*PAGE_SIZE;
loff_tend=(range->pgend+1)*PAGE_SIZE-1;
vmtruncate_range(inode, start,end);
range->purged=ASHMEM_WAS_PURGED;
lru_del(range);
nr_to_scan-=range_size(range);if(nr_to_scan<=0)
break;
}
mutex_unlock(&ashmem_mutex);
return lru_count;
}
cache_shrinker同样先取得了ashmem_mutex，通过list_for_each_entry_safe来确保其被安全释放。该方法会被mm/vmscan.c :: shrink_slab调用，其中参数nr_to_scan表示有多少个页面对象。如果该参数为0，则表示查询所有的页面对象总数。而“gfp_mask”是一个配置，返回值为被回收之后剩下的页面数量;如果返回-1，则表示由于配置文件(gfp_mask)产生的问题，使得mutex_lock不能进行安全的死锁。
Ashmem的源代码实现很简单，注释和代码总共不到700行。主要因为它借助了Linux内核已经有的工具，例如shmem_file_setup(支撑文件)和cache_shrinker(slab分配算法用于页面回收的回调函数)等，实现了高效的内存使用和管理，但是用户需进行额外的ioctl调用来设置名字和大小，以及执行pin和unpin操作等。
到这里，对Ashmem驱动的分析已经结束了。因为我们讲述的是实现的原理和机制，所以没有将代码全部贴出来，建议大家参考源代码进行理解。
Low Memory Killer(低内存管理)
对于PC来说，内存是至关重要。如果某个程序发生了内存泄漏，那么一般情况下系统就会将其进程Kill掉。Linux中使用一种名称为OOM(Out Of Memory，内存不足)的机制来完成这个任务，该机制会在系统内存不足的情况下，选择一个进程并将其Kill掉。Android则使用了一个新的机制——Low Memory Killer来完成同样的任务。下面首先来看看Low Memory Killer机制的原理以及它是如何选择将被Kill的进程的。
1.Low Memory Killer的原理和机制
Low Memory Killer在用户空间中指定了一组内存临界值，当其中的某个值与进程描述中的oom_adj值在同一范围时，该进程将被Kill掉。通常，在“/sys/module/lowmemorykiller / parameters/adj”中指定oom_adj的最小值，在“/sys/module/lowmemorykiller/parameters/minfree”中储存空闲页面的数量，所有的值都用一个逗号将其隔开且以升序排列。比如：把“0,8”写入到/sys/module/lowmemorykiller/parameters/adj中，把“1024,4096”写入到/sys/module/lowmemory- killer/parameters/minfree中，就表示当一个进程的空闲存储空间下降到4096个页面时，oom_adj值为8或者更大的进程会被Kill掉。同理，当一个进程的空闲存储空间下降到1024个页面时，oom_adj值为0或者更大的进程会被Kill掉。我们发现在lowmemorykiller.c中就指定了这样的值，如下所示：
staticintlowmem_adj[6]={0,1,6,12,
};
staticintlowmem_adj_size=4;
static size_t lowmem_minfree[6]={3*512,//6MB2*1024,//8MB4*1024,//16MB16*1024,//64MB
};
staticintlowmem_minfree_size=4;
这就说明，当一个进程的空闲空间下降到3´512个页面时，oom_adj值为0或者更大的进程会被Kill掉;当一个进程的空闲空间下降到2´1024个页面时，oom_adj值为10或者更大的进程会被Kill掉，依此类推。其实更简明的理解就是满足以下条件的进程将被优先Kill掉：
task_struct->signal_struct->oom_adj越大的越优先被Kill。
占用物理内存最多的那个进程会被优先Kill。
进程描述符中的signal_struct->oom_adj表示当内存短缺时进程被选择并Kill的优先级，取值范围是-17~15。如果是-17，则表示不会被选中，值越大越可能被选中。当某个进程被选中后，内核会发送SIGKILL信号将其Kill掉。
实际上，Low Memory Killer驱动程序会认为被用于缓存的存储空间都要被释放，但是，如果很大一部分缓存存储空间处于被锁定的状态，那么这将是一个非常严重的错误，并且当正常的oom killer被触发之前，进程是不会被Kill掉的。
2.Low Memory Killer的具体实现
在了解了Low Memory Killer的原理之后，我们再来看如何实现这个驱动。Low Memory Killer驱动的实现位于drivers/misc/lowmemorykiller.c。
该驱动的实现非常简单，其初始化与退出操作也是我们到目前为止见过的最简单的，代码如下：
staticint__init lowmem_init(void)
{
register_shrinker(&lowmem_shrinker);
return0;
}
static void __exit lowmem_exit(void)
{
unregister_shrinker(&lowmem_shrinker);
}
module_init(lowmem_init);
module_exit(lowmem_exit);
在初始化函数lowmem_init中通过register_shrinker注册了一个shrinker为lowmem_shrinker;退出时又调用了函数lowmem_exit，通过unregister_shrinker来卸载被注册的lowmem_shrinker。其中lowmem_shrinker的定义如下：
static struct shrinker lowmem_shrinker={
.shrink=lowmem_shrink,
.seeks=DEFAULT_SEEKS*16};
lowmem_shrink是这个驱动的核心实现，当内存不足时就会调用lowmem_shrink方法来Kill掉某些进程。下面来分析其具体实现，实现代码如下：
staticintlowmem_shrink(intnr_to_scan, gfp_t gfp_mask)
{
struct task_struct*p;
struct task_struct*selected=NULL;intrem= 0;inttasksize;inti;intmin_adj=OOM_ADJUST_MAX+1;intselected_tasksize=0;intarray_size=ARRAY_SIZE(lowmem_adj);intother_free=global_page_state(NR_FREE_PAGES);intother_file=global_page_state(NR_FILE_PAGES);if(lowmem_adj_size
array_size=lowmem_adj_size;if(lowmem_minfree_size
array_size=lowmem_minfree_size;for(i=0; i
min_adj=lowmem_adj[i];
break;
}
}if(nr_to_scan>0)
lowmem_print(3,"lowmem_shrink %d, %x, ofree %d %d, ma %d\n", nr_to_scan,
gfp_mask, other_free, other_file, min_adj);rem= global_page_state(NR_ACTIVE_ANON) +global_page_state(NR_ACTIVE_FILE)+global_page_state(NR_INACTIVE_ANON)+global_page_state(NR_INACTIVE_FILE);if(nr_to_scan<=0|| min_adj==OOM_ADJUST_MAX+1) {
lowmem_print(5,"lowmem_shrink %d, %x, return %d\n", nr_to_scan, gfp_mask,rem);returnrem;}
read_lock(&tasklist_lock);
for_each_process(p) {if(p->oomkilladjmm)
continue;
tasksize=get_mm_rss(p->mm);if(tasksize<=0)
continue;if(selected) {if(p->oomkilladjoomkilladj)
continue;if(p->oomkilladj==selected->oomkilladj&&tasksize<=selected_tasksize)
continue;
}
selected=p;
selected_tasksize=tasksize;
lowmem_print(2,"select %d (%s), adj %d, size %d, to kill\n",
p->pid, p->comm, p->oomkilladj, tasksize);
}if(selected !=NULL) {
lowmem_print(1,"send sigkill to %d (%s), adj %d, size %d\n",
selected->pid, selected->comm,
selected->oomkilladj, selected_tasksize);
force_sig(SIGKILL, selected);rem-= selected_tasksize;}
lowmem_print(4,"lowmem_shrink %d, %x, return %d\n", nr_to_scan, gfp_mask,rem);read_unlock(&tasklist_lock);
returnrem;}
可以看出，其中多处用到了global_page_state函数。有很多人找不到这个函数，其实它被定义在了linux/vmstat.h中，其参数使用zone_stat_item枚举，被定义在linux/mmzone.h中，具体代码如下：
enum zone_stat_item {
NR_FREE_PAGES,
NR_LRU_BASE,
NR_INACTIVE_ANON=NR_LRU_BASE,
NR_ACTIVE_ANON,
NR_INACTIVE_FILE,
NR_ACTIVE_FILE,
#ifdef CONFIG_UNEVICTABLE_LRU
NR_UNEVICTABLE,
NR_MLOCK,
#elseNR_UNEVICTABLE=NR_ACTIVE_FILE,NR_MLOCK=NR_ACTIVE_FILE,
#endif
NR_ANON_PAGES,NR_FILE_MAPPED,NR_FILE_PAGES,
NR_FILE_DIRTY,
NR_WRITEBACK,
NR_SLAB_RECLAIMABLE,
NR_SLAB_UNRECLAIMABLE,
NR_PAGETABLE,
NR_UNSTABLE_NFS,
NR_BOUNCE,
NR_VMSCAN_WRITE,
NR_WRITEBACK_TEMP,#ifdef CONFIG_NUMA
NUMA_HIT,NUMA_MISS,NUMA_FOREIGN,
NUMA_INTERLEAVE_HIT,
NUMA_LOCAL,NUMA_OTHER,#endif
NR_VM_ZONE_STAT_ITEMS };
再回过头来看owmem_shrink函数，首先确定我们所定义的lowmem_adj和lowmem_minfree数组的大小(元素个数)是否一致，如果不一致则以最小的为基准。因为我们需要通过比较lowmem_minfree中的空闲储存空间的值，以确定最小min_adj值(当满足其条件时，通过其数组索引来寻找lowmem_adj中对应元素的值);之后检测min_adj的值是否是初始值“OOM_ADJUST_MAX + 1”，如果是，则表示没有满足条件的min_adj值，否则进入下一步;然后使用循环对每一个进程块进行判断，通过min_adj来寻找满足条件的具体进程(主要包括对oomkilladj和task_struct进行判断);最后，对找到的进程进行NULL判断，通过“force_sig(SIGKILL, selected)”发送一条SIGKILL信号到内核，Kill掉被选中的“selected”进程。
关于Low Memory Killer的分析就到这里，在了解了其机制和原理之后，我们发现它的实现非常简单，与标准的Linux OOM机制类似，只是实现方式稍有不同。标准Linux的OOM Killer机制在mm/oom_kill.c中实现，且会被__alloc_pages_may_oom调用(在分配内存时，即mm/page_alloc.c中)。oom_kill.c最主要的一个函数是out_of_memory，它选择一个bad进程Kill，Kill的方法同样是通过发送SIGKILL信号。在out_of_memory中通过调用select_bad_process来选择一个进程Kill，选择的依据在badness函数中实现，基于多个标准来给每个进程评分，评分最高的被选中并Kill。一般而言，占用内存越多，oom_adj就越大，也就越有可能被选中。
Logger(日志设备)
我们在开发Android应用的过程中可以很方便地使用Log信息来调试程序，这都归功于Android的Logger驱动为用户层提供的Log支持。无论是底层的源代码还是上层的应用，我们都可以使用Logger这个日志设备来进行调试。Logger一共包括三个设备节点，它们分别是：
/dev/log/main
/dev/log/event
/dev/log/radio
其驱动程序的实现源文件位于：
include/linux/logger.h
include/linux/logger.c
下面将对该驱动的实现进行分析，首先打开logger.h文件，我们可以看到如下所示的一个结构体logger_entry，它定义了每一条日志信息的属性。
struct logger_entry {
__u16len;
__u16 __pad;
__s32 pid;
__s32 tid;
__s32 sec;
__s32 nsec;
char msg[0];
};
其中，len表示日志信息的有效长度;__pad目前没有什么实质作用，但是需要使用两个字节来占位;pid表示生成该日志信息的进程的pid;tid表示生成该日志信息的进程的tid;sec表示生成该日志的时间，单位是秒;nsec表示当生成该日志的时间不足1秒时，用纳秒来计算;msg储存着该日志的有效信息，即我们前面说的长度为len的日志信息属于有效信息。
此外，还定义了代表不同设备事件的宏，分别对应于Logger的三个不同的设备节点，如下所示：
#define LOGGER_LOG_RADIO "log_radio"
#define LOGGER_LOG_EVENTS "log_events"
#define LOGGER_LOG_MAIN "log_main"
接下来在logger.c中还定义了logger_log结构体，它定义每一个日志设备的相关信息。我们上面所说的radio、events和main都将使用logger_log结构体来表示，定义如下：
struct logger_log {
unsigned char*buffer;
struct miscdevice misc;
wait_queue_head_t wq;
struct list_head readers;
struct mutex mutex;
size_t w_off;
size_t head;
size_t size;
};
其中，buffer表示该设备储存日志的环形缓冲区，(为什么是环形缓冲区，后面将给大家解释);misc代表日志设备的miscdevice，在注册设备的时候需要使用;wq表示一个等待队列，等待在该设备上读取日志的进程readers;readers表示读取日志的readers链表;mutex则是用于多线程同步和保护该结构体的mutex;w_off代表当前写入日志的位置，即在环形缓冲区中(buffer)的偏移量;head是一个读取日志的新的readers，表示从这里开始读取，同样指在环形缓冲区中(buffer)的偏移量;size则代表该日志的大小，即环形缓冲区中(buffer)的大小。
根据上面这个日志设备结构logger_log可以得知，要读取日志还需要一个用于读取日志的readers。下面我们来分析一下readers的定义，其结构体位于logger.c中的logger_reader结构体中，代码如下：
struct logger_reader {
struct logger_log*log;
struct list_head list;
size_t r_off;
};
logger_reader结构体的实现就很简单，其中log代表相关的日志设备，即当前将要读取数据的日志设备(logger_log);list用于指向日志设备的读取进程(readers);r_off则表示开始读取日志的一个偏移量，即日志设备中将要被读取的buffer的偏移量。
了解了这些数据结构之后，我们来分析一下该驱动是如何工作的，即该驱动的工作流程。
1.logger_init
首先还是来看其初始化方式，如下所示：
staticint__init logger_init(void)
{intret;
ret=init_log(&log_main);if(unlikely(ret))gotoout;
ret=init_log(&log_events);if(unlikely(ret))gotoout;
ret=init_log(&log_radio);if(unlikely(ret))gotoout;
out:
return ret;
}
device_initcall(logger_init);
当系统内核启动后，在init过程中就会调用device_initcall所指向的logger_init来初始化日志设备。我们可以看到，在logger_init函数中正好调用了init_log函数来初始化前面所提到的日志系统的三个设备节点。下面我们来看看init_log函数中究竟是如何初始化这些设备节点的。init_log的实现如下：
staticint__init init_log(struct logger_log*log)
{intret;
ret=misc_register(&log->misc);if(unlikely(ret)) {
printk(KERN_ERR"logger: failed to register misc""device for log '%s'!\n",log->misc.name);
return ret;
}
printk(KERN_INFO"logger: created %luK log '%s'\n",
(unsignedlong)log->size>>10,log->misc.name);
return0;
}
非常简单，通过调用misc_register来初始化每个日志设备的miscdevice(logger_log->misc)。我们并没有看到具体的初始化日志设备的操作，那是因为这些工作都由DEFINE_LOGGER_ DEVICE宏来完成了，DEFINE_LOGGER_DEVICE的实现如下：
#define DEFINE_LOGGER_DEVICE(VAR, NAME, SIZE)
static unsigned char _buf_ ## VAR[SIZE];
static struct logger_log VAR={
.buffer=_buf_ ## VAR,
.misc={
.minor=MISC_DYNAMIC_MINOR,
.name=NAME,
.fops=&logger_fops,
.parent=NULL,
},
.wq=__WAIT_QUEUE_HEAD_INITIALIZER(VAR .wq),
.readers=LIST_HEAD_INIT(VAR .readers),
.mutex=__MUTEX_INITIALIZER(VAR .mutex),
.w_off=0,
.head=0,
.size=SIZE,
};
DEFINE_LOGGER_DEVICE需要我们传入三个参数，其作用就是使用参数NAME作为名称和使用SIZE作为尺寸来创建一个日志设备。这里需要注意：SIZE的大小必须为2的幂，并且要大于LOGGER_ENTRY_MAX_LEN，小于LONG_MAX-LOGGER_ENTRY_ MAX_ LEN。该宏的定义如下(源代码在logger.h文件中)，表示日志的最大长度，同时还定义了LOGGER_ ENTRY_MAX_PAYLOAD表示日志的最大有效长度。
#define LOGGER_ENTRY_MAX_LEN (4*1024)
#define LOGGER_ENTRY_MAX_PAYLOAD
(LOGGER_ENTRY_MAX_LEN - sizeof(struct logger_entry))
有了这些定义之后，现在要初始化一个日志设备就变得非常简单，以下代码初始化了三个不同的日志设备：
DEFINE_LOGGER_DEVICE(log_main, LOGGER_LOG_MAIN, 64*1024)
DEFINE_LOGGER_DEVICE(log_events, LOGGER_LOG_EVENTS, 256*1024)
DEFINE_LOGGER_DEVICE(log_radio, LOGGER_LOG_RADIO, 64*1024)
在初始化过程中，我们为设备指定了对应的file_operations，其定义如下：
static struct file_operations logger_fops={
.owner=THIS_MODULE,
.read=logger_read,
.aio_write=logger_aio_write,
.poll=logger_poll,
.unlocked_ioctl=logger_ioctl,
.compat_ioctl=logger_ioctl,
.open=logger_open,
.release=logger_release,
};
其中主要包括了关于日志设备的各种操作函数和接口，比如：读取日志的logger_read、打开日志设备文件的logger_open读取数据的logger_read，等等。下面，我们将分别对这些函数的实现进行分析。
2.logger_open
该方法为打开日志设备文件的方法，具体实现如下：
staticintlogger_open(struct inode*inode, struct file*file)
{
struct logger_log*log;intret;
ret=nonseekable_open(inode, file);if(ret)
return ret;//判断类型log=get_log_from_minor(MINOR(inode->i_rdev));if(!log)
return-ENODEV;//只读模式if(file->f_mode&FMODE_READ) {
struct logger_reader*reader;
reader=kmalloc(sizeof(struct logger_reader), GFP_KERNEL);if(!reader)
return-ENOMEM;//指定日志设备
reader->log=log;
INIT_LIST_HEAD(&reader->list);//指定mutex
mutex_lock(&log->mutex);//指定读取偏移量
reader->r_off=log->head;
list_add_tail(&reader->list,&log->readers);
mutex_unlock(&log->mutex);//保存数据到private_data
file->private_data=reader;
}else//读写模式
file->private_data=log;
return0;
}
该函数首先调用get_log_from_minor函数来判断需要打开的日志设备的类型，判断方法非常简单，直接判断日志设备的misc.minor参数和minor参数即可，实现代码如下：
static struct logger_log*get_log_from_minor(intminor)
{if(log_main.misc.minor==minor)
return&log_main;if(log_events.misc.minor==minor)
return&log_events;if(log_radio.misc.minor==minor)
return&log_radio;
returnNULL;
}
再回过头来看logger_open函数，在取得了日志设备的类型之后，我们需要判断其读写模式。如果是只读模式，则将创建一个logger_reader，然后对其所需的数据进行初始化(指定日志设备、mutex、读取偏移量r_off)，最后将该logger_reader保存到file->private_data中;如果是读写模式或者写模式，则直接将日志设备log保存到file->private_data中，这样做就方便我们在以后的读写过程中直接通过file->private_data来取得logger_reader和logger_log。
3.logger_release
在分析了打开操作之后，我们再来看一下释放操作，具体实现如下：
staticintlogger_release(struct inode*ignored, struct file*file)
{if(file->f_mode&FMODE_READ) {
struct logger_reader*reader=file->private_data;
list_del(&reader->list);
kfree(reader);
}
return0;
}
首先判断其是否为只读模式，如果是只读模式，则直接通过file->private_data取得其对应的logger_reader，然后删除其队列并释放即可。写操作则没有额外分配空间，所以不需要处理。
4.logger_read
接下来分析一下读数据的操作方法，其实现代码如下：
static ssize_t logger_read(struct file*file, char __user*buf,
size_t count, loff_t*pos)
{//通过file->private_data获取logger_reader及其日志设备logger_log
struct logger_reader*reader=file->private_data;
struct logger_log*log=reader->log;
ssize_t ret;
DEFINE_WAIT(wait);
start:while(1) {//添加进程到等待队列
prepare_to_wait(&log->wq,&wait, TASK_INTERRUPTIBLE);
mutex_lock(&log->mutex);
ret=(log->w_off==reader->r_off);
mutex_unlock(&log->mutex);if(!ret)
break;if(file->f_flags&O_NONBLOCK) {
ret=-EAGAIN;
break;
}if(signal_pending(current)) {
ret=-EINTR;
break;
}
schedule();
}
finish_wait(&log->wq,&wait);if(ret) return ret;
mutex_lock(&log->mutex);if(unlikely(log->w_off==reader->r_off)) {
mutex_unlock(&log->mutex);gotostart;
}//读取下一条日志
ret=get_entry_len(log, reader->r_off);if(count
ret=-EINVAL;gotoout;
}//复制到用户空间
ret=do_read_log_to_user(log, reader, buf, ret);
out:
mutex_unlock(&log->mutex);
return ret;
}
整体过程比较简单，但是这里需要注意：我们首先是通过prepare_to_wait函数将当前进程添加到等待队列log->wq之中，通过偏移量来判断当前日志的buffer是否为空。如果为空，则调度其他的进程运行，自己挂起;如果指定了非阻塞模式，则直接返回EAGAIN。然后，通过while循环来重复该过程，直到buffer中有可供读取的日志为止。最后，通过get_entry_len函数读取下一条日志，并通过do_read_log_to_user将其复制到用户空间，读取完毕。
5.logger_aio_write
分析了读操作，下面登场的应该是写操作了。在这里，我们终于可以清楚地向大家解释之前的疑问——为什么缓冲区是环形的。在写入日志时，当其日志缓冲区buffer被写满之后，我们就不能再执行写入操作了吗?答案是否定的，正因为buffer是环形的，在写满之后，新写入的数据就会覆盖最初的数据，所以我们需要采取一定的措施来避免原来的数据被覆盖，以免造成数据丢失。写操作的具体实现如下：
ssize_t logger_aio_write(struct kiocb*iocb,conststruct iovec*iov,
unsignedlongnr_segs, loff_t ppos)
{//取得日志设备logger_log
struct logger_log*log=file_get_log(iocb->ki_filp);
size_t orig=log->w_off;
struct logger_entry header;
struct timespecnow;
ssize_t ret=0;now=current_kernel_time();//初始化日志数据logger_entry
header.pid=current->tgid;
header.tid=current->pid;
header.sec=now.tv_sec;
header.nsec=now.tv_nsec;
header.len=min_t(size_t, iocb->ki_left, LOGGER_ENTRY_MAX_PAYLOAD);if(unlikely(!header.len))
return0;
mutex_lock(&log->mutex);//修正偏移量，避免被覆盖
fix_up_readers(log, sizeof(struct logger_entry)+header.len);//写入操作
do_write_log(log,&header, sizeof(struct logger_entry));while(nr_segs-->0) {
size_tlen;
ssize_t nr;len=min_t(size_t, iov->iov_len, header.len-ret);//从用户空间写入日志
nr=do_write_log_from_user(log, iov->iov_base,len);if(unlikely(nr<0)) {log->w_off=orig;
mutex_unlock(&log->mutex);
return nr;
}
iov++;
ret+=nr;
}
mutex_unlock(&log->mutex);
wake_up_interruptible(&log->wq);
return ret;
}
与读操作一样，首先，需要取得日志设备logger_log，这里我们是通过file_get_log函数来获取日志设备;然后，对要写入的日志执行初始化操作(包括进程的pid、tid和时间等)。因为我们的写操作支持同步、异步以及scatter等方式(非常灵活)，而且在进行写操作时读操作可能并没有发生，这样就会被覆盖，所以通过在写操作之前执行fix_up_readers函数来修正其偏移量(r_off)，然后才执行真正的写入操作。
fix_up_readers函数真正能修正其偏移量而使其不被覆盖吗?下面我们先看看该函数的具体实现，如下所示：
static void fix_up_readers(struct logger_log*log, size_tlen)
{//当前写偏移量
size_t old=log->w_off;//写入长度为len的数据后的偏移量
size_tnew=logger_offset(old+len);
struct logger_reader*reader;if(clock_interval(old,new,log->head))//查询下一个log->head=get_next_entry(log,log->head,len);//遍历reader链表
list_for_each_entry(reader,&log->readers, list)if(clock_interval(old,new, reader->r_off))
reader->r_off=get_next_entry(log, reader->r_off,len);
}
大家可以看到，在执行clock_interval进行new复制时，将会覆盖log->head，所以我们使用get_next_entry来查询下一个节点，并使其作为head节点。通常在执行查询时，我们使用的都是要被写入的整个数据的长度(len)，因为是环形缓冲区，所以会出现覆盖数据的情况，因此这里传入的长度为最大长度(即要写入的数据长度);然后遍历reader链表，如果reader在覆盖范围内，那么调整当前reader位置到下一个log数据区。因此从这里我们可以看出，fix_up_readers函数只是起到一个缓解的作用，也不能最终解决数据覆盖问题，所以写入的数据如果不被及时读取，则会造成数据丢失。
6.logger_poll
该函数用来判断当前进程是否可以对日志设备进行操作，其具体实现代码如下：
static unsignedintlogger_poll(struct file*file, poll_table*wait)
{
struct logger_reader*reader;
struct logger_log*log;
unsignedintret=POLLOUT | POLLWRNORM;if(!(file->f_mode&FMODE_READ))
return ret;
reader=file->private_data;log=reader->log;
poll_wait(file,&log->wq, wait);
mutex_lock(&log->mutex);//判断是否为空if(log->w_off !=reader->r_off)
ret |=POLLIN | POLLRDNORM;
mutex_unlock(&log->mutex);
return ret;
}
我们可以看出，POLLOUT总是成立的，即进程总是可以进行写入操作;读操作则不一样了，如果只是以FMODE_READ模式打开日志设备的进程，那么就需要判断当前日志缓冲区是否为空，只有不为空才能读取日志。
7.logger_ioctl
该函数主要用于对一些命令进行操作，它可以支持以下命令操作：
LOGGER_GET_LOG_BUF_SIZE得到日志环形缓冲区的尺寸
LOGGER_GET_LOG_LEN得到当前日志buffer中未被读出的日志长度
LOGGER_GET_NEXT_ENTRY_LEN得到下一条日志长度
LOGGER_FLUSH_LOG清空日志
它们分别对应于logger.h中所定义的下面这些宏：
#define LOGGER_GET_LOG_BUF_SIZE_IO(__LOGGERIO, 1)
#define LOGGER_GET_LOG_LEN_IO(__LOGGERIO, 2)
#define LOGGER_GET_NEXT_ENTRY_LEN_IO(__LOGGERIO, 3)
#define LOGGER_FLUSH_LOG_IO(__LOGGERIO, 4)
这些操作的具体实现很简单，大家可以参考logger.c中的logger_ioctl函数。以上就是我们对Logger驱动的分析，大家可以对应源码来阅读，这样会更容易理解。