Re: [RFC v3] mm: add page preemption

Re: [RFC v3] mm: add page preemption

[Matthew Wilcox]

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.

Re: [RFC v3] mm: add page preemption

[David Hildenbrand]

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