Android对Linux内核的增强

转自：http://tech.it168.com/a2011/0805/1228/000001228471.shtml

　【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_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驱动的相关参数，具体如下所示：

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来对其执行锁定和解锁操作。实现代码如下：

static int __init alarm_late_init(void)
{
    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驱动。实现代码如下：

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_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页面的区域，代码如下：

struct ashmem_area {
    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。到这里，初始化操作则完成了，实现代码如下：

static int __init ashmem_init(void)
{
    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函数的具体实现：

static void __exit ashmem_exit(void)
{
    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设备，其中包含的相关方法及其作用如下面的代码所示。

static struct file_operations ashmem_fops = {
    .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函数的实现如下：

static int ashmem_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);

    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分配算法用于页面回收的回调函数。具体实现如下：

static int ashmem_shrink(int nr_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_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中就指定了这样的值，如下所示：

static int lowmem_adj[6] = {
    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。

　　该驱动的实现非常简单，其初始化与退出操作也是我们到目前为止见过的最简单的，代码如下：

static int __init lowmem_init(void)
{
    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的定义如下：

static struct shrinker lowmem_shrinker = {
    .shrink = lowmem_shrink,
    .seeks = DEFAULT_SEEKS * 16
};

　　lowmem_shrink是这个驱动的核心实现，当内存不足时就会调用lowmem_shrink方法来Kill掉某些进程。下面来分析其具体实现，实现代码如下：

static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
{
    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中，具体代码如下：

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,
#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，它定义了每一条日志信息的属性。

struct 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结构体来表示，定义如下：

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

　　首先还是来看其初始化方式，如下所示：

static int __init logger_init(void)
{
    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的实现如下：

static int __init init_log(struct logger_log *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的实现如下：

#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

　　该方法为打开日志设备文件的方法，具体实现如下：

static int logger_open(struct inode *inode, struct file *file)
{
    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参数即可，实现代码如下：

static struct logger_log * get_log_from_minor(int 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

　　在分析了打开操作之后，我们再来看一下释放操作，具体实现如下：

static int logger_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);
    }
    return 0;
}

　　首先判断其是否为只读模式，如果是只读模式，则直接通过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);
        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是环形的，在写满之后，新写入的数据就会覆盖最初的数据，所以我们需要采取一定的措施来避免原来的数据被覆盖，以免造成数据丢失。写操作的具体实现如下：

ssize_t logger_aio_write(struct kiocb *iocb, const struct iovec *iov,
             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函数真正能修正其偏移量而使其不被覆盖吗?下面我们先看看该函数的具体实现，如下所示：

static void fix_up_readers(struct logger_log *log, size_t len)
{
    //当前写偏移量
    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

　　该函数用来判断当前进程是否可以对日志设备进行操作，其具体实现代码如下：

static unsigned int logger_poll(struct file *file, poll_table *wait)
{
    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驱动的分析，大家可以对应源码来阅读，这样会更容易理解。