On Sun, Nov 03, 2019 at 07:57:27PM +0800, Hillf Danton wrote: > The cpu preemption feature makes a task able to preempt other tasks > of lower priorities for cpu. It has been around for a while. > > This work introduces task prio into page reclaiming in order to add > the page preemption feature that makes a task able to preempt other > tasks of lower priorities for page. > > No page will be reclaimed on behalf of tasks of lower priorities > under pp, a two-edge feature that functions only under memory > pressure, laying a barrier to pages flowing to lower prio, and the > nice syscall is what users need to fiddle with it for instance if > they have a bunch of workloads to run in datacenter, and some > difficulty predicting the runtime working set size for every > individual workload which is sensitive to jitters in lru pages. > > Currently pages are reclaimed without prio taken into account; pages > can be reclaimed from tasks of lower priorities on behalf of > higher-prio tasks and vice versa. > > s/and vice versa/only/ is what we need to make pp by definition, but > it could not make a sense without prio introduced; otherwise we can > simply skip deactivating the lru pages based on prio comprison, and > work is done. > > The introduction consists of two parts. On the page side, we have to > store the page owner task's prio in page, which needs an extra room the > size of the int type in the page struct. That room sounds impossible > without inflating the page struct size, and is walked around by making > pp depend on CONFIG_64BIT. ... and !MEMCG. Which means that your work is uninteresting because all the distros turn on CONFIG_MEMCG. You still haven't given us any numbers. Or a workload which actually benefits from this patch.
