CN115328856B - 一种文件页管理的方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种文件页管理的方法、装置、电子设备及存储介质，所述方法包括：获取重访问请求，并依据重访问请求在已回收文件页中确定重访问文件页；获取重访问文件页对应的重访问数量；获取当前场景对应的场景参数，并依据场景参数及重访问数量确定重访问文件页是否存入重要链表，场景参数用于表征该场景下的内存占用情况；若是，则将文件页存入重要链表中。本申请是依据场景的内存占用情况及重访问文件页对应的重访问数量来决定是否将该重访问文件页存入重要链表，能够精准识别不同场景中能够放入重要链表的重要文件页，进而实现对不同场景下的重要文件页的有效保护，避免出现因对文件页过度保护导致的内存浪费的情况。

Description

一种文件页管理的方法、装置及电子设备

【技术领域】

本申请涉及文件页管理领域，具体而言，涉及一种文件页管理的方法、装置、电子设备及计算机可读存储介质。

【背景技术】

由于读写硬盘的速度比读写内存要慢很多，所以为了避免每次读写文件时，都需要对硬盘进行读写操作，Linux内核使用页缓存机制来对文件中的数据进行缓存。Linux以页大小为单位将磁盘中的数据缓存在内存中，这些页面被管理在最近最少使用算法(LeastRecently Used，LRU)链表中。

对于文件页缓存，Linux维护了两中类型的链表：活跃链表(active LRU)和不活跃链表(inactive LRU)。简单来说就是，经常访问的文件页被放在active LRU链表中，不经常使用的文件也被放在inacitve LRU链表中。回收内存时，首先回收inactive LRU链表中的文件页，然后才会回收active LRU链表中的文件页。也就是说active LRU中保存的文件在内存中驻留的时间更长。

然而对于小内存设备来说，当内存压力紧张时，active LRU链表中的文件页依然会被回收。为了解决上述问题，现有的方式为新增一条LRU链表用以存储重要文件页，且在内存回收时，需先回收inacitve LRU链表，再回收active LRU链表，最后再回收新增的LRU链表。这样可以保护在新增的LRU链表中文件页缓存相比于active LRU具有更长的驻留时间。然而现有方案是靠人为识别或者单一模型测试出来重要文件页，这种方式只能够针对某个场景有效，对于大部分场景来说是无效的，过度的保护这类文件页反而会造成内存的浪费。

因此，如何为不同场景下的重要文件页提供有效保护为本领域需要解决的技术问题。

【发明内容】

为了解决现有技术中无法为不同场景下的重要文件页提供有效保护的问题，本申请提供一种文件页管理的方法。

一种文件页管理的方法，包括：

获取重访问请求，并依据所述重访问请求确定重访问文件页，所述重访问文件页为回收后再次被访问的文件页；

获取所述重访问文件页对应的重访问数量，所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量；

获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，所述场景参数用于表征该场景下的内存占用情况；

若是，则将所述重访问文件页存入所述重要链表中。

优选地，所述场景参数大于一；

所述依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，包括：

获取活跃链表内存储的文件页的第一数量，并计算所述第一数量与所述场景参数的商；

判断所述重访问数量是否大于所述第一数量与所述场景参数的商；

若是，则确定所述重访问文件页存入所述重要链表。

优选地，当所述重访问数量大于或等于所述第一数量与所述场景参数的商时，所述方法还包括：

判断所述重访问数量是否大于所述第一数量；

若否，则确定所述重访问文件页存入活跃链表；

若是，则确定所述重访问文件页存入非活跃链表。

优选地，在将所述重访问文件页存入所述重要链表中之后，所述方法还包括：

获取内存回收请求，并依据所述内存回收请求确定第二数量；

从非活跃链表中回收所述第二数量的文件页，并将活跃链表中所述第二数量的文件页降级至所述非活跃链表中。

优选地，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，所述方法还包括：

获取所述重要链表中存储的文件页的第三数量，并判断所述第三数量是否大于预设阈值；

若是，则确定所述第三数量与所述预设阈值的差值为第四数量，并将所述重要链表中所述第四数量的文件页降级至所述活跃链表中；

若否，则对所述重要链表中的文件页不作降级处理。

优选地，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，所述方法还包括：

将所述重要链表中所述第二数量的文件页降级至所述活跃链表中。

优选地，所述获取当前场景对应的场景参数，包括：

获取预设对应关系表，并依据所述预设对应关系表根据当前场景确定当前场景对应的场景参数，所述预设对应关系表用于表征场景与场景参数的对应关系。

一种文件页管理装置，包括：

第一获取模块，用于获取重访问请求，并依据所述重访问请求确定重访问文件页，所述重访问文件页为回收后再次被访问的文件页；

第二获取模块，用于获取所述重访问文件页对应的重访问数量，所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量；

第三获取模块，用于获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，所述场景参数用于表征该场景下的内存占用情况；

存储模块，用于若确定所述重访问文件页存入所述重要链表，则将所述重访问文件页存入所述重要链表中。

一种电子设备，包括：

处理器和存储器，所述存储器用于存储至少一条指令，所述指令由所述处理器加载并执行时以实现如上述的文件页管理的方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的文件页管理的方法。

本申请实施例提供的文件页管理的方法，通过依据重访问请求在已回收文件页中确定重访问文件页，然后依据重访问文件页对应的重访问数量以及当前场景对应的场景参数来确定重访问文件页是否存入重要链表，其中场景参数用于表征该场景下的内存占用情况，即本申请是依据场景的内存占用情况及重访问文件页对应的重访问数量来决定是否将该重访问文件页存入重要链表，能够精准识别不同场景中能够放入重要链表的重要文件页，进而实现对不同场景下的重要文件页的有效保护，避免出现因对文件页过度保护导致的内存浪费的情况。

【附图说明】

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例所提供的一种页缓存的示意图；

图2为现有技术中的一种内存抖动解决方案的示意图；

图3为本申请实施例所提供的一种文件页管理的方法的流程图；

图4为本申请实施例所提供的另一种文件页管理的方法的流程图；

图5为本申请实施例所提供的一种内存抖动解决方案的示意图；

图6为本申请实施例所提供的一种文件页管理装置的结构示意图。

【具体实施方式】

为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。

应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

为了便于理解，本申请实施例这里介绍本申请实施例涉及的术语：

1)、页缓存：为了提升对文件的读写效率，Linux内核会以页大小(4KB)为单位，将文件划分为多数据块。当用户对文件中的某个数据块进行读写操作时，内核首先会申请一个文件页(称为页缓存)与文件中的数据块进行绑定。请参考图1，为本申请实施例所提供的一种页缓存的示意图，如图1所示，当用户对文件进行读写时，实际上是对文件的页缓存进行读写。所以对文件进行读写操作时，会分为以下两种情况进行处理：

当从文件中读取数据时，如果要读取的数据所在的页缓存已经存在，那么就直接把页缓存的数据拷贝给用户即可。否则，内核首先会申请一个空闲的内存页(页缓存)，然后从文件中读取数据到页缓存，并且把页缓存的数据拷贝给用户。

当向文件中写入数据时，如果要写入的数据所在的页缓存已经存在，那么直接把新数据写入到页缓存即可。否则，内核首先会申请一个空闲的内存页(页缓存)，然后从文件中读取数据到页缓存，并且把新数据写入到页缓存中。对于被修改的页缓存，内核会定时把这些页缓存刷新到文件中。

2)、内存抖动：内存抖动是指在短时间内有大量的对象被创建或者被回收的现象。内存抖动产生原因主要是频繁在循环里创建对象(导致大量对象在短时间内被创建，由于新对象是要频繁占用内存空间的，如果在循环里频繁创建对象会对内存产生很大影响，造成严重内存抖动)。如果内存抖动很频繁，会导致垃圾回收机制频繁运行，造成系统卡顿。

3)、页面回收算法：该算法目前只针对页缓存类型的页面。对于页缓存类型的LRU链表来说，有两个链表值得关注，分别是活跃链表和不活跃链表。新产生的页总是加入到不活跃链表的头部，页面回收也总是从不活跃链表的尾部开始回收。不活跃链表的页面第二次访问时会升级(promote)到活跃链表，防止被回收；另一方面如果活跃链表增长太快，那么活跃的页面会被降级(demote)到不活跃链表中。

请参考图2，为现有技术中的一种内存抖动解决方案的示意图。

如图2所示，新加入的文件页直接添加到inactive LRU链表的头部；当回收内存时，从inactive LRU链表的尾部回收文件页；重访问文件页表示已回收文件页再一次被内核访问；文件页降级表示当内存压力紧张需要回收active LRU链表时，从active LRU链表的尾部将文件页降级到inactive LRU链表中。

实际上有一些场景，某些页面经常被访问，但是它们在下一次被访问之前就在不活跃链表中被回收并释放了，那么又必须从存储系统中读取这些页缓存页面，这些场景下产生抖动现象。

内核原生内存抖动解决方案为了解决该问题，引入了重访问(refaults)算法，具体如下：

当图2中的重访问数量小于active LRU链表中的文件页数量时，将重访问文件页加入到active LRU链表中；否则，将重访问文件页加入到inactive LRU链表中。

然而对于小内存设备来说，当内存压力紧张时，active LRU链表中的文件页依然会被回收。为了解决上述问题，现有的方式为新增一条LRU链表，保护在该链表中文件页缓存相比于active LRU具有更长的驻留时间。然而现有方案是靠人为识别或者单一模型测试出来的重要文件页，只能够针对某个场景有效，对于大部分场景来说是无效的，过度的保护这类文件页反而会造成内存的浪费。故本申请提供了一种文件页管理的方法，用于解决上述问题。

实施例一

请参考图3，为本申请实施例所提供的一种文件页管理的方法的流程图，包括如下步骤：

步骤S01，获取重访问请求，并依据所述重访问请求确定重访问文件页。

在一个具体实施例中，重访问请求即为对已回收文件页进行第二次访问的请求，当回收内存时，从inactive LRU链表中回收文件页，即为将inactive LRU链表尾部的文件页中的数据删除，并将该文件页所占用的内存释放，如果需要对已被回收的文件页中的数据进行再次访问，此时操作系统内核会发起重访问请求，处理器依据该重访问请求确定待访问的数据对应的文件页为该重访问文件页。

在本申请实施例中，重访问文件页为回收后再次被访问的文件页，即表示文件页被回收后再一次被内核访问，当存在文件页被再次访问时，则证明该文件页的访问频率比较高，此时需要判断该文件页是否为需要存入重要链表的重要文件页。

在一个具体实施例中，重访问请求是由操作系统内核发送的，操作系统内核在接收到输入的访问请求时，依据该访问请求确定出待访问的数据，然后依据待访问的数据确定对应的文件页，如果该文件页以前访问过并且此时已被回收，则发送该重访问请求，因此本申请实施例中的获取重访问请求，其具体可以为接收操作系统内核发送的重访问请求。

在一个具体实施例中，该重访问请求包括待访问数据块的信息，依据重访问请求在已回收文件页中确定重访问文件页，其具体可以为：

在已回收文件页中查找与该待访问数据块的信息相匹配的文件页，并确定与该待访问数据块的信息相匹配的文件页为该重访问文件页。

在一个具体实施例中，文件页从第一次被访问到第二次被访问需要经过如下过程：

文件页第一次访问时会加入到inactive LRU链表表头，随着inactive LRU链表尾部的文件页不断被回收，该文件页也会慢慢从链表头向链表尾移动直至被回收，当文件页被第二次访问(即重访问)时，会依据场景参数及重访问数量来确定该文件页加入重要链表、active LRU链表或inactive LRU链表，以便内核访问存储于链表中的该文件页。

步骤S02，获取所述重访问文件页对应的重访问数量。

在本申请实施例中，重访问数量为重访问文件页从回收到重访问之间的时间间隔内被回收的文件页的数量。

在本申请实施例中，计算重访问文件页对应的重访问数量的目的在于，依据重访问数量来确定该重访问文件页是否为需要加入重要链表的重要文件页，进而确定该重访问文件页的存储位置。

下面结合具体实施例来对重访问数量进行解释，如图2所示，在一个具体实施例中，inactive LRU链表具有如下特征：

1)文件页第一次访问时会加入到inactive LRU链表表头，随着inactive LRU链表尾部的文件页不断被回收，该文件页也会慢慢从链表头向链表尾移动直至被回收，这个过程叫做移出(eviction)。

2)当文件页被第二次访问(即重访问)时，如果文件页被升级到active LRU链表，由于active LRU链表长度是固定的，那么active LRU链表尾部的文件页会降级到inactiveLRU链表中，这个过程叫作降级(demotion)。

3)移出过程处理的文件页数量与激活过程处理的文件页数量的和等于inactiveLRU链表中文件页的数量NR_inactive。

4)要从inactive LRU链表中将新加入的文件页释放，需要回收N个文件页(N＝inactive LRU链表中文件页的数量)。

基于上述行为特征，第一次访问文件页称为fault，第二次访问该文件页称为refault，该文件页第一次被踢出inactive LRU链表并回收的时刻称为E，第二次再访问该文件页的时刻称为R，那么R-E的时间里回收的文件页数量称为重访问数量(RefaultDistance)。

依据重访问数量和第一次访问该文件页的时刻，可以得到该文件页第一次访问和第二次访问之间的时间间隔内被回收的文件页的数量(read_distance)，即：

read_distance＝NR_inactive+Refault Distance

如果想保证该文件页一直存储于内存中不被回收，那么则需要保证该文件页一直保持在inactive LRU链表或active LRU链表中，即该文件页第一次访问和第二次访问之间的时间间隔内被回收的文件页的数量read_distance应该小于inactive LRU链表中文件页的数量与active LRU链表中文件页的数量的和，否则该文件页将会被回收，即：

read_distance＝NR_inactive+Refault Distance<NR_inactive+NR_active

可得：Refault Distance<NR_active

也就是说，如果文件页的重访问数量大于active LRU链表中文件页的数量，那么该文件页第一次访问和第二次访问之间的时间间隔内被回收的文件页的数量read_distance也会大于inactive LRU链表与active LRU链表整体能存储的文件页的数量，即使将该文件页放入active LRU链表，该文件页最终也会被回收，因此现有技术中的做法为：

将重访问数量大于active LRU链表中文件页的数量(Refault Distance>NR_active)的文件页直接存入inactive LRU链表；

将重访问数量小于active LRU链表中文件页的数量(Refault Distance<NR_active)的文件页直接存入active LRU链表，进而保证存入active LRU链表中的文件页能够一直存储于内存中不被回收。

然而对于小内存设备来说，当内存压力紧张时，active LRU链表中的文件页依然会被回收。因此本申请新增一条重要链表，该重要链表用于保护重要文件页，令在该重要链表中的重要文件页相比于active LRU链表中的文件页具有更长的驻留时间，而且本申请中是依据场景参数及重访问数量共同确定重访问文件页是否存入重要链表的，能够精准识别不同场景中能够放入重要链表的重要文件页，进而实现对不同场景下的重要文件页的有效保护，避免出现因对文件页过度保护导致的内存浪费的情况。

步骤S03，获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表。

若是，则执行步骤S04。

在本申请实施例中，该场景参数用于表征该场景下的内存占用情况，即本申请实施例能够依据当前场景的内存占用情况动态决定是否将重访问文件页存入重要链表，精准识别不同场景的重要文件页，进而实现对不同场景下的重要文件页的有效保护，避免出现因对文件页过度保护导致的内存浪费的情况。

在一个具体实施例中，可以预先建立每个场景与对应的场景参数的对应关系，在获取当前场景对应的场景参数时，依据该对应关系确定当前场景对应的场景参数；该预设的对应关系具体可以为存有场景与对应的场景参数的对应关系表，也可以为其他形式的用于表征该对应关系的数据结构。

即本申请实施例中的获取当前场景对应的场景参数，其具体可以为：

获取预设对应关系表，并依据所述预设对应关系表根据当前场景确定当前场景对应的场景参数，所述预设对应关系表用于表征场景与场景参数的对应关系。

在一个具体实施例中，这里提到的获取当前场景对应的场景参数，其具体也可以为，依据场景的变化，按照预设规则对场景参数进行动态调整。例如：在面对游戏场景时，高动态画面的切换导致内存压力紧张，需要文件页频繁的换入换出，此时需要把场景参数调大，只保护高频访问的文件页；在面对浏览视频、听音乐、看小说或浏览页面等场景时，内存压力不大，不需要文件页频繁的换入换出，但是又想保护一些关键的文件，此时可以把场景参数调小，即只要是在这个场景下的重访问文件页都保护起来。

在一个具体实施例中，该场景参数大于零，即本申请实施例中的依据场景参数及重访问数量确定重访问文件页是否存入重要链表，其具体可以为：

计算活跃链表内文件页的第一数量与场景参数的差值；

判断重访问数量是否小于该活跃链表内文件页的第一数量与场景参数的差值；

若是，则确定重访问文件页存入重要链表。

在现有技术中依据重访问数量与活跃链表内文件页的第一数量的大小关系确定文件页存入活跃链表和不活跃链表的基础上，本申请实施例中文件页存放位置的确定是依据重访问文件页的重访问数量与该第一数量和该场景参数的差值的大小关系来确定的，如果该重访问数量小于该差值，则证明该重访问文件页两次访问的时间间隔更短，即表明该重访问文件页在被回收之后很快又被访问到，也就是说，在此场景下该重访问文件页的访问频率特别频繁，因此需要将该重访问文件页存入重要链表进行重点保护。

在一个具体实施例中，该场景参数大于一，本申请实施例中的依据场景参数及重访问数量确定重访问文件页是否存入重要链表，其具体也可以为：

获取活跃链表内存储的文件页的第一数量，并计算所述第一数量与所述场景参数的商；

判断所述重访问数量是否大于所述第一数量与所述场景参数的商；

若是，则确定所述重访问文件页存入所述重要链表。

在本申请实施例中，也可以将第一数量与场景参数的商作为是否将重访问文件页存入重要链表的判断依据，因为场景参数大于一，所以第一数量与场景参数的商是小于第一数量的，在此情况下如果重访问数量小于该第一数量与该场景参数的商，则证明该重访问文件页两次访问的时间间隔更短，即表明该重访问文件页在被回收之后很快又被访问到，也就是说，在此场景下该重访问文件页的访问频率特别频繁，因此需要将该重访问文件页存入重要链表进行重点保护。

在上述实施例的基础上，在一个具体实施例中，当重访问数量大于或等于该第一数量与场景参数的商时，所述方法还包括：

判断所述重访问数量是否大于所述第一数量；

若否，则确定所述重访问文件页存入活跃链表；

若是，则确定所述重访问文件页存入非活跃链表。

在本申请实施例中，当重访问数量大于或等于该第一数量与场景参数的商时，则证明该重访问文件页两次访问的时间间隔没有特别短，也就是说，在此场景下该重访问文件页的访问频率没有达到需要存入重要链表的程度，此时本申请依据重访问数量与第一数量的大小关系，来确定重访问文件页存入活跃链表或非活跃链表：

当重访问数量大于第一数量时，则证明重访问文件页第一次访问和第二次访问之间的时间间隔内被回收的文件页的数量也会大于活跃链表与非活跃链表整体能存储的文件页的数量，即使将该文件页放入活跃链表，该文件页最终也会被回收，因此当重访问数量大于第一数量时，确定重访问文件页存入活跃链表。

当重访问数量小于或等于第一数量时，则证明重访问文件页第一次访问和第二次访问之间的时间间隔内被回收的文件页的数量小于或等于活跃链表与非活跃链表整体能存储的文件页的数量，即将重访问文件页放入活跃链表后，重访问文件页会在被回收之前被重新访问，进而能够保证存入活跃链表后的重访问文件页能够一直存储于内存中不被回收，因此当重访问数量小于或等于第一数量时，确定重访问文件页存入活跃链表。

步骤S04，将所述重访问文件页存入所述重要链表中。

在本申请实施例中，该重要链表相对于活跃链表和非活跃链表具有更高的重要级别，使得存储于重要链表中的文件页相比于活跃链表和非活跃链表中的文件页具有更长的驻留时间，进而在面对内存回收情况时，能够先回收非活跃链表中的文件页，再回收活跃链表中的文件页，最后回收重要链表中的文件页，使得能够对存入重要链表的重访问文件页提供有效保护。

本申请实施例提供的文件页管理的方法，通过依据重访问请求在已回收文件页中确定重访问文件页，然后依据重访问文件页对应的重访问数量以及当前场景对应的场景参数来确定重访问文件页是否存入重要链表，其中场景参数用于表征该场景下的内存占用情况，即本申请是依据场景的内存占用情况及重访问文件页对应的重访问数量来决定是否将该重访问文件页存入重要链表，能够精准识别不同场景中能够放入重要链表的重要文件页，进而实现对不同场景下的重要文件页的有效保护，避免出现因对文件页过度保护导致的内存浪费的情况。

实施例二

请参考图4，为本申请实施例所提供的另一种文件页管理的方法的流程图，该方法包括如下步骤：

步骤S01，获取重访问请求，并依据所述重访问请求确定重访问文件页。

所述重访问文件页为回收后再次被访问的文件页。

步骤S02，获取所述重访问文件页对应的重访问数量。

所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量。

步骤S03，获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表。

若是，则进入步骤S04。

所述场景参数用于表征该场景下的内存占用情况。

步骤S04，将所述重访问文件页存入所述重要链表中。

步骤S11：获取内存回收请求，并依据所述内存回收请求确定第二数量。

在一个具体实施例中，在面对有新的内存分配请求时，如果剩余内存不足以支撑此次内存分配，此时系统会回收一部分内存，进而尽可能地满足新内存分配请求，即本申请实施例中的获取内存回收请求，其具体可以为：

接收系统发送的内存回收请求。

在一个具体实施例中，内存回收请求中包括待回收文件页的第二数量，在接收到该内存回收请求后，解析该内存回收请求得到该待回收文件页的第二数量。

步骤S12：从非活跃链表中回收所述第二数量的文件页，并将活跃链表中所述第二数量的文件页降级至所述非活跃链表中。

在确定需要回收的文件页的第二数量以后，本申请从非活跃链表中回收第二数量的文件页，即从非活跃链表中将第二数量的文件页回收释放，以使系统能够在内存回收后满足新的内存回收需求；而在非活跃链表中文件页回收完之后，非活跃链表出现文件页空缺状态，此时为保证下一次内存回收能够正常进行，对活跃链表中的文件页进行降级处理，即将活跃链表中第二数量的文件页降级至非活跃链表中。

在一个具体实施例中，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，活跃链表也出现了文件页空缺的情况，为了避免影响后续的内存回收，还可以将所述重要链表中所述第二数量的文件页降级至所述活跃链表中。

在一个具体实施例中，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，活跃链表也出现了文件页空缺的情况，此时还可以依据重要链表中文件页的数量来决定是否对重要链表中的文件页进行降级处理，即还可以执行如下步骤：

步骤S21：获取所述重要链表中存储的文件页的第三数量，并判断所述第三数量是否大于预设阈值。

若是，则执行步骤S22；若否，则执行步骤S23。

本申请实施例中的预设阈值用于表征重要链表中允许存放文件页的最大数量，该预设阈值可以为用户自行设定的，也可以为文件页管理装置依据场景参数计算得到的，还可以为文件页管理装置连接到指定服务器或者通过指定存储路径获取得到的，本申请对预设阈值的获取方式不作具体限定。

步骤S22：确定所述第三数量与所述预设阈值的差值为第四数量，并将所述重要链表中所述第四数量的文件页降级至所述活跃链表中。

步骤S23，对所述重要链表中的文件页不作降级处理。

本申请实施例在面对将活跃链表中第二数量的文件页降级至非活跃链表中时，先通过判断该重要链表中文件页的第三数量与预设阈值的大小关系，如果第三数量超出预设阈值，则证明重要链表中存储的文件页数量超过了允许数量，此时将超出部分的文件页降级到活跃链表中；如果没超出预设阈值，则证明重要链表中存储的文件页数量未超过允许数量，此时对重要链表中的文件页不作降级处理，以保护重要链表中的文件页。

需要说明的是，本实施例中的步骤S01至S04与实施例一中的步骤S01至S03技术方案及有益效果一致，在此不再赘述。

实施例三

请参考图5，为本申请实施例所提供的一种内存抖动解决方案的示意图。

如图5所示，本申请在现有的内存抖动解决方案上新增了一个重要LRU链表和一种加入到重要LRU链表的判断逻辑。整个文件页访问的过程包括如下步骤：

步骤S31，文件页第一次访问时会加入到inactive LRU链表表头，然后慢慢从链表头向链表尾移动，链表尾的文件页会被移出inactive LRU链表并且释放页面。

步骤S32，当文件页被第二次访问(即重访问)时，获取重访问文件页对应的重访问数量，即重访问文件页从回收到重访问之间的时间间隔内被回收的文件页的数量。

步骤S33，获取当前场景对应的场景参数ratio，计算active LRU链表中文件页的数量与场景参数ratio的商NR_active/ratio。

步骤S34，根据重访问数量与NR_active/ratio的大小关系确定是否将重访问文件页存入重要链表，如果重访问数量Refault Distance<NR_active/ratio，则确定将重访问文件页存入重要链表。

步骤S35，如果Refault Distance≥NR_active/ratio，则根据重访问数量与active LRU链表中文件页的数量NR_active的大小关系确定将重访问文件页存入活跃链表或者非活跃链表。

步骤S36，如果Refault Distance≤NR_active，则确定将重访问文件页存入活跃链表；如果Refault Distance>NR_active，则确定将重访问文件页存入非活跃链表。

实施例四

请参考图6，为本申请实施例所提供的一种文件页管理装置的结构示意图，该装置包括：

第一获取模块10，用于获取重访问请求，并依据所述重访问请求确定重访问文件页，所述重访问文件页为回收后再次被访问的文件页；

第二获取模块20，用于获取所述重访问文件页对应的重访问数量，所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量；

第三获取模块30，用于获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，所述场景参数用于表征该场景下的内存占用情况；

存储模块40，用于若确定所述重访问文件页存入所述重要链表，则将所述重访问文件页存入所述重要链表中。

在上述实施例的基础上，在一个具体实施例中，所述场景参数大于一；

所述第三获取模块30具体用于：

获取活跃链表内存储的文件页的第一数量，并计算所述第一数量与所述场景参数的商；

判断所述重访问数量是否大于所述第一数量与所述场景参数的商；

若是，则确定所述重访问文件页存入所述重要链表。

在上述实施例的基础上，在一个具体实施例中，所述第三获取模块30还用于：

当所述重访问数量大于或等于所述第一数量与所述场景参数的商时，判断所述重访问数量是否大于所述第一数量；

若否，则确定所述重访问文件页存入活跃链表；

若是，则确定所述重访问文件页存入非活跃链表。

在上述实施例的基础上，在一个具体实施例中，所述存储模块40还用于：

获取内存回收请求，并依据所述内存回收请求确定第二数量；

从非活跃链表中回收所述第二数量的文件页，并将活跃链表中所述第二数量的文件页降级至所述非活跃链表中。

在上述实施例的基础上，在一个具体实施例中，所述存储模块40还用于：

获取所述重要链表中存储的文件页的第三数量，并判断所述第三数量是否大于预设阈值；

若是，则确定所述第三数量与所述预设阈值的差值为第四数量，并将所述重要链表中所述第四数量的文件页降级至所述活跃链表中；

若否，则对所述重要链表中的文件页不作降级处理。

在上述实施例的基础上，在一个具体实施例中，所述存储模块40还用于：

将所述重要链表中所述第二数量的文件页降级至所述活跃链表中。

在上述实施例的基础上，在一个具体实施例中，所述第三获取模块30具体用于：

获取预设对应关系表，并依据所述预设对应关系表根据当前场景确定当前场景对应的场景参数，所述预设对应关系表用于表征场景与场景参数的对应关系。

实施例六

本实施例提供一种电子设备，包括处理器和存储器，存储器用于存储至少一条指令，指令由处理器加载并执行时以实现上述的文件页管理的方法，其执行方式和有益效果类似，在这里不再赘述。

本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的文件页管理的方法，其执行方式和有益效果类似，在这里不再赘述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种文件页管理的方法，其特征在于，包括：

获取重访问请求，并依据所述重访问请求确定重访问文件页，所述重访问文件页为回收后再次被访问的文件页；

获取所述重访问文件页对应的重访问数量，所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量；

获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，所述场景参数用于表征该场景下的内存占用情况；

若是，则将所述重访问文件页存入所述重要链表中。

2.根据权利要求1所述的方法，其特征在于，所述场景参数大于一；

所述依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，包括：

获取活跃链表内存储的文件页的第一数量，并计算所述第一数量与所述场景参数的商；

判断所述重访问数量是否大于所述第一数量与所述场景参数的商；

若是，则确定所述重访问文件页存入所述重要链表。

3.根据权利要求2所述的方法，其特征在于，当所述重访问数量大于或等于所述第一数量与所述场景参数的商时，所述方法还包括：

判断所述重访问数量是否大于所述第一数量；

若否，则确定所述重访问文件页存入活跃链表；

若是，则确定所述重访问文件页存入非活跃链表。

4.根据权利要求1所述的方法，其特征在于，在将所述重访问文件页存入所述重要链表中之后，所述方法还包括：

获取内存回收请求，并依据所述内存回收请求确定第二数量；

从非活跃链表中回收所述第二数量的文件页，并将活跃链表中所述第二数量的文件页降级至所述非活跃链表中。

5.根据权利要求4所述的方法，其特征在于，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，所述方法还包括：

获取所述重要链表中存储的文件页的第三数量，并判断所述第三数量是否大于预设阈值；

若是，则确定所述第三数量与所述预设阈值的差值为第四数量，并将所述重要链表中所述第四数量的文件页降级至所述活跃链表中；

若否，则对所述重要链表中的文件页不作降级处理。

6.根据权利要求4所述的方法，其特征在于，在将活跃链表中所述第二数量的文件页降级至所述非活跃链表中之后，所述方法还包括：

将所述重要链表中所述第二数量的文件页降级至所述活跃链表中。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述获取当前场景对应的场景参数，包括：

获取预设对应关系表，并依据所述预设对应关系表根据当前场景确定当前场景对应的场景参数，所述预设对应关系表用于表征场景与场景参数的对应关系。

8.一种文件页管理装置，其特征在于，包括：

第一获取模块，用于获取重访问请求，并依据所述重访问请求确定重访问文件页，所述重访问文件页为回收后再次被访问的文件页；

第二获取模块，用于获取所述重访问文件页对应的重访问数量，所述重访问数量为所述重访问文件页从回收到重访问之间的时间段内被回收的文件页的数量；

第三获取模块，用于获取当前场景对应的场景参数，并依据所述场景参数及所述重访问数量确定所述重访问文件页是否存入重要链表，所述场景参数用于表征该场景下的内存占用情况；

存储模块，用于若确定所述重访问文件页存入所述重要链表，则将所述重访问文件页存入所述重要链表中。

9.一种电子设备，其特征在于，包括：

处理器和存储器，所述存储器用于存储至少一条指令，所述指令由所述处理器加载并执行时以实现如权利要求1-7中任意一项所述的文件页管理的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7中任意一项所述的文件页管理的方法。

Images