On 04.11.19 04:01, Hillf Danton wrote:
On Sun, 3 Nov 2019 09:06:49 -0800 Matthew Wilcox wrote:
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.
I have no idea which one they turn on by default, ext4, btrfs or xfs,
and why, but I think they feel free to do the right, or the left.
So do users to configure and build the kernel they need to power their
machines, a 4-socket server or a TV-top box.
You still haven't given us any numbers. Or a workload which actually
benefits from this patch.
Though I do not know why it is turned on by distros and for what
workloads, I would like to try to run a couple of the workloads you
may have interest in.
Why do you keep posting RFC if you don't care about feedback? That's not
how upstream work works, really.
Please finally fix your mail client for good as already noted in:
https://www.spinics.net/lists/linux-mm/msg194683.html
--
Thanks,
David / dhildenb
