【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
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返回标记的枚举类型如下：
ANDROID_ALARM_RTC_WAKEUP_MASK = 1U << ANDROID_ALARM_RTC_WAKEUP,
ANDROID_ALARM_RTC_MASK = 1U << ANDROID_ALARM_RTC,
ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP_MASK =
1U << ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP,
ANDROID_ALARM_ELAPSED_REALTIME_MASK =
1U << ANDROID_ALARM_ELAPSED_REALTIME,
ANDROID_ALARM_SYSTEMTIME_MASK = 1U << ANDROID_ALARM_SYSTEMTIME,
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驱动的相关参数，具体如下所示：
.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接口信息，主要包括设备的添加和移除操作，内容如下：
.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来对其执行锁定和解锁操作。实现代码如下：
{
unsigned long flags;
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);
return 0;
}
3.alarm_exit
当Alarm退出时，就需要通过class_interface_unregister函数来卸载在初始化时注册的Alarm接口，通过wake_lock_destroy函数来销毁SUSPEND lock，以及通过platform_driver_unregister函数来卸载Alarm驱动。实现代码如下：
{
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设备。其包括的主要特性如下面的代码所示：
.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触发的方法，其定义如下：
.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_PURGED 0
#define ASHMEM_WAS_PURGED 1
//从ASHMEM_GET_PIN_STATUS返回的值，判断是pin还是unpin
#define ASHMEM_IS_UNPINNED 0
#define ASHMEM_IS_PINNED 1
struct ashmem_pin {
__u32 offset; //在Ashmem区域的偏移量
__u32 len; //从偏移量开始的长度
};
另外一些宏用于设置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页面的区域，代码如下：
char name[ASHMEM_FULL_NAME_LEN];/* 用于/proc/pid/maps中的一个标识名称 */
struct list_head unpinned_list; /* 所有的匿名共享内存区列表 */
struct file *file; /* Ashmem所支持的文件 */
size_t size; /* 字节数 */
unsigned long prot_mask; /* vm_flags */
};
struct ashmem_range {
struct list_head lru; /* LRU列表 */
struct list_head unpinned; /* unpinned列表 */
struct ashmem_area *asma; /* ashmem_area结构 */
size_t pgstart; /* 开始页面 */
size_t pgend; /* 结束页面 */
unsigned int purged; /* 是否需要清除（ASHMEM_NOT_PURGED 或者ASHMEM_WAS_PURGED） */
};
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。到这里，初始化操作则完成了，实现代码如下：
{
int ret;
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");
return 0;
}
当Ashmem退出时，又该执行什么操作呢?下面是Ashmem退出时需要执行的ashmem_exit函数的具体实现：
{
int ret;
/* 卸载回收函数 */
unregister_shrinker(&ashmem_shrinker);
/* 卸载Ashmem设备 */
ret = misc_deregister(&ashmem_misc);
if (unlikely(ret))
printk(KERN_ERR "ashmem: failed to unregister misc device!\n");
/* 卸载cache */
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设备，其中包含的相关方法及其作用如下面的代码所示。
.owner = THIS_MODULE,
.open = ashmem_open, /* 打开Ashmem */
.release = ashmem_release, /* 释放Ashmem */
.mmap = ashmem_mmap, /* mmap函数 */
.unlocked_ioctl = ashmem_ioctl, /* 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函数的实现如下：
{
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);
return 0;
}
接下来就是将分配的空间映射到进程空间。在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分配算法用于页面回收的回调函数。具体实现如下：
{
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_t end = (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中就指定了这样的值，如下所示：
0,
1,
6,
12,
};
static int lowmem_adj_size = 4;
static size_t lowmem_minfree[6] = {
3*512, // 6MB
2*1024, // 8MB
4*1024, // 16MB
16*1024, // 64MB
};
static int lowmem_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。
该驱动的实现非常简单，其初始化与退出操作也是我们到目前为止见过的最简单的，代码如下：
{
register_shrinker(&lowmem_shrinker);
return 0;
}
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的定义如下：
.shrink = lowmem_shrink,
.seeks = DEFAULT_SEEKS * 16
};
lowmem_shrink是这个驱动的核心实现，当内存不足时就会调用lowmem_shrink方法来Kill掉某些进程。下面来分析其具体实现，实现代码如下：
{
struct task_struct *p;
struct task_struct *selected = NULL;
int rem = 0;
int tasksize;
int i;
int min_adj = OOM_ADJUST_MAX + 1;
int selected_tasksize = 0;
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
int other_file = global_page_state(NR_FILE_PAGES);
if(lowmem_adj_size < array_size)
array_size = lowmem_adj_size;
if(lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for(i = 0; i < array_size; i++) {
if (other_free < lowmem_minfree[i] &&
other_file < lowmem_minfree[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);
return rem;
}
read_lock(&tasklist_lock);
for_each_process(p) {
if (p->oomkilladj < min_adj || !p->mm)
continue;
tasksize = get_mm_rss(p->mm);
if (tasksize <= 0)
continue;
if (selected) {
if (p->oomkilladj < selected->oomkilladj)
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);
return rem;
}
可以看出，其中多处用到了global_page_state函数。有很多人找不到这个函数，其实它被定义在了linux/vmstat.h中，其参数使用zone_stat_item枚举，被定义在linux/mmzone.h中，具体代码如下：
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,
#else
NR_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，它定义了每一条日志信息的属性。
__u16 len;
__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结构体来表示，定义如下：
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_log * log;
struct list_head list;
size_t r_off;
};
logger_reader结构体的实现就很简单，其中log代表相关的日志设备，即当前将要读取数据的日志设备(logger_log);list用于指向日志设备的读取进程(readers);r_off则表示开始读取日志的一个偏移量，即日志设备中将要被读取的buffer的偏移量。
了解了这些数据结构之后，我们来分析一下该驱动是如何工作的，即该驱动的工作流程。
1.logger_init
首先还是来看其初始化方式，如下所示：
{
int ret;
ret = init_log(&log_main);
if (unlikely(ret))
goto out;
ret = init_log(&log_events);
if (unlikely(ret))
goto out;
ret = init_log(&log_radio);
if (unlikely(ret))
goto out;
out:
return ret;
}
device_initcall(logger_init);
当系统内核启动后，在init过程中就会调用device_initcall所指向的logger_init来初始化日志设备。我们可以看到，在logger_init函数中正好调用了init_log函数来初始化前面所提到的日志系统的三个设备节点。下面我们来看看init_log函数中究竟是如何初始化这些设备节点的。init_log的实现如下：
{
int ret;
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",
(unsigned long) log->size >> 10, log->misc.name);
return 0;
}
非常简单，通过调用misc_register来初始化每个日志设备的miscdevice(logger_log->misc)。我们并没有看到具体的初始化日志设备的操作，那是因为这些工作都由DEFINE_LOGGER_ DEVICE宏来完成了，DEFINE_LOGGER_DEVICE的实现如下：
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，其定义如下：
.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
该方法为打开日志设备文件的方法，具体实现如下：
{
struct logger_log *log;
int ret;
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;
return 0;
}
该函数首先调用get_log_from_minor函数来判断需要打开的日志设备的类型，判断方法非常简单，直接判断日志设备的misc.minor参数和minor参数即可，实现代码如下：
{
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;
return NULL;
}
再回过头来看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
在分析了打开操作之后，我们再来看一下释放操作，具体实现如下：
{
if (file->f_mode & FMODE_READ) {
struct logger_reader *reader = file->private_data;
list_del(&reader->list);
kfree(reader);
}
return 0;
}
首先判断其是否为只读模式，如果是只读模式，则直接通过file->private_data取得其对应的logger_reader，然后删除其队列并释放即可。写操作则没有额外分配空间，所以不需要处理。
4.logger_read
接下来分析一下读数据的操作方法，其实现代码如下：
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);
goto start;
}
//读取下一条日志
ret = get_entry_len(log, reader->r_off);
if (count < ret) {
ret = -EINVAL;
goto out;
}
//复制到用户空间
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是环形的，在写满之后，新写入的数据就会覆盖最初的数据，所以我们需要采取一定的措施来避免原来的数据被覆盖，以免造成数据丢失。写操作的具体实现如下：
unsigned long nr_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 timespec now;
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))
return 0;
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_t len;
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函数真正能修正其偏移量而使其不被覆盖吗?下面我们先看看该函数的具体实现，如下所示：
{
//当前写偏移量
size_t old = log->w_off;
//写入长度为len的数据后的偏移量
size_t new = 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
该函数用来判断当前进程是否可以对日志设备进行操作，其具体实现代码如下：
{
struct logger_reader *reader;
struct logger_log *log;
unsigned int ret = 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驱动的分析，大家可以对应源码来阅读，这样会更容易理解。
