首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Per process reclaim

    These day, there are many platforms avaiable in the embedded market and they are smarter than kernel which has very limited information about working set so they want to involve memory management more heavily like android's lowmemory killer and ashmem or recent many lowmemory notifier(there was several trial for various company NOKIA, SAMSUNG, Linaro, Google ChromeOS, Redhat). One of the simple imagine scenario about userspace's intelligence is thatplatform can manage tasks as forground and backgroud so it would be better to reclaim background's task pages for end-user's *responsibility* although it has frequent referenced pages. Minchan Kim provide these patches in 2013, Whihc adds new knob "reclaim under proc/<pid>/" so task managercan reclaim any target process anytime, anywhere. It could give another method to platform for using memory efficiently. It can avoid process killing for getting free memory, which was really terrible experience if these apps are killed by OOO killer. How it worksReclaim file-backed pages only. echo file > /proc/PID/reclaim Reclaim anonymous pages only. echo anon > /proc/PID/reclaim Reclaim all pages echo all > /proc/PID/reclaim Some pages could be shared by several processes. (ex, libc) In case of that, it's too bad to reclaim them from the beginnig. It can let VM keep them on memory until last task try to reclaim them so shared pages will be reclaimed only if all of task has gone swapping out. Another requirement is per address space reclaim.(By Michael Kerrisk) In case of Webkit1, it uses a address space for handling multi tabs. IOW, it uses *one* process model so all tabs shares address space of the process. In such scenario, per-process reclaim is rather coarse-grained and now supports more fine-grained reclaim for being able to reclaim target address range of the process. For reclaim target range, you should use following format. echo [addr] [size-byte] > /proc/pid/reclaim

    02

    Artifacts VS OPA

    1 过程财富库的含义 CMMI中提到的organizational process assets 通常翻译为组织过程资产或者是组织过程财富,可以简写为OPA。 什么是OPA呢?按照V1.3中的术语定义: Artifacts that relate to describing, implementing, and improving processes. Examples of these artifacts include policies, measurement descriptions, process descriptions, process implementation support tools. The term “process assets” is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value. (See also “process asset library.”) 对上述的定义需要这么来理解: (1) the artifacts of describing processes,描述过程的制品,如方针、度量元定义、过程定义、规程定义、指南等; (2) the artifacts of implementing processes,实施过程的制品,如文档模板、过程裁剪报告、检查单等; (3) the artifacts of improving processes,改进过程的制品,如过程改进建议、经验教训总结等; 之所以用”assets”这个单词是从投资回报的角度来讲,过程财富不是只有投入没有产出的,是可以给我们带来回报的,过程财富服务于商业目标的。 在OPD过程域中SP 1.7 Establish Rules and Guidelines for Teams中还描述了在组织过程资产中还包括了: 团队结构指南; 团队信息指南; 团队授权和职责指南; 建立沟通渠道、授权和扩编指南; 团队负责人筛选准则等。 由以上可以看出,凡事在组织内有共享价值的与管理有关的资料都可以称为过程财富。 2 过程财富库中的内容 对于过程财富库在CMMI中做了如下的定义: A library of information used to store and make process assets available that are useful to those who are defining, implementing, and managing processes in the organization. This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons learned documents, templates, standards, procedures, plans, and training materials. 对于过程财富库中的内容在SP 1.5 Establish the Organization’s Process Asset Library中作了如下的举例: 过程财富库中包含了如下的内容: 组织级的方针; 过程描述; 规程(如估算规程); 开发计划; 采购计划; 质量保证计划; 培训材料; 过程支持工具(如检查单); 经验教训报告等。 在这个举例中,列举的3个计划,可以理解为是计划的模板,而不是某个项目的具体计划,如果是理解为某个项目的具

    02

    [linux][redis]redis支持disable-thp了

    前言 前文《[linux][redis]bgsave引起的latency突刺问题分析》中记录了在执行bgsave的时候,因为fork子进程之后,会出现page fault导致了redis的延迟受到了影响。 前文《[THP][redis]THP对redis的影响》中分析了THP(transparent hugepage)对redis的延迟突刺的影响。 大约两年半以前,作者给redis提了PR(https://github.com/redis/redis/pull/5124),但是maintainer并没有回复,一段时间后关闭。 几个月前,第二次提PR(https://github.com/redis/redis/pull/7381)希望解决这个问题,新任的maintainer Oran对THP问题比较感兴趣,同时也把三年多以前的另外一个PR(https://github.com/redis/redis/pull/4001)翻了出来。大约经过一周的讨论和修改,两个PR都已经合入了upstream。 分析 THP的内核逻辑 内核提供了THP开关可以控制,/sys/kernel/mm/transparent_hugepage/enabled,这个开关需要root权限,且是系统级别的影响。 always表示所有的进程都会被khugepaged扫描,尝试使用2M的透明大页。 madvise表示如果有进程调用了THP开关,则打开/关闭。 never表示khugepaged不会对任何进程生效,包括使用madvise的进程。 warning判断 redis的原有的逻辑是在启动阶段检查系统的THP配置,如果不是never,就会产生一个warning。redis自身并没有使用过madvise进行THP操作,即使使用了jemalloc,也不会对主要的内存进行THP操作。所以改成不是always就应该是安全的,所以,Oran接受了这个改动(https://github.com/redis/redis/pull/4001)。 关闭redis的进程THP 更加理想的做法是不管系统配置如何,redis都可以把自己进程的THP开关禁用掉,这样子不需要root权限控制,且不会影响其他的进程。Linux恰好提供了这样了一个syscall,所以在(https://github.com/redis/redis/pull/7381)中,会关闭掉。同时,根据Oran的意见,增加了配置项,在多数情况下,默认都是会自动关闭掉THP,除非用户强制指定了不关闭的配置。这样下来,在大多数情况下,用户都可以避免THP引起的fork之后的剧烈抖动问题。 关于conf的描述 在redis.conf中增加了一个新的配置项“disable-thp”,作者最初的描述是

    02
    领券