Background page clearing

Background page clearing

[Wilco Dijkstra]

Hi,

I recently noticed how a Stream benchmark took 30% more time in the first iteration due to having to
clean pages in the output array. Especially clearing a huge page on a pagefault is a substantial
overhead. It affects the cached data of the workload while it is running and reduces available
memory bandwidth.

Is there a reason Linux does not do background page clearing like other OSes to reduce this
overhead? It would be a good fit for typical mobile workloads (bursts of high activity followed by
periods of low activity).

Wilco



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Background page clearing

[Dave Hansen]

On 07/25/2014 08:06 AM, Wilco Dijkstra wrote:
> Is there a reason Linux does not do background page clearing like other OSes to reduce this
> overhead? It would be a good fit for typical mobile workloads (bursts of high activity followed by
> periods of low activity).

If the page is being allocated, it is about to be used and be brought in
to the CPU's cache.  If we zero it close to this use, we only pay to
bring it in to the CPU's cache once.  Or so goes the theory...

I tried a zero-on-free implementation a year or so ago.  It helped some
workloads and hurt others.  The gains were not large enough or
widespread enough to merit pushing it in to the kernel.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: Background page clearing

[Wilco Dijkstra]

> On 07/25/2014 08:06 AM, Wilco Dijkstra wrote:
> > Is there a reason Linux does not do background page clearing like other OSes to reduce this
> > overhead? It would be a good fit for typical mobile workloads (bursts of high activity
> followed by
> > periods of low activity).
>
> If the page is being allocated, it is about to be used and be brought in
> to the CPU's cache.  If we zero it close to this use, we only pay to
> bring it in to the CPU's cache once.  Or so goes the theory...

I can see the reasoning for 4KB pages and small allocations (eg. stack),
but would that ever be true for huge pages?

> I tried a zero-on-free implementation a year or so ago.  It helped some
> workloads and hurt others.  The gains were not large enough or
> widespread enough to merit pushing it in to the kernel.

Was that literally zero-on-free or zero in the background? Was the result
the same for different page sizes? My guess is that the result will be
different for huge pages.

Wilco

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Background page clearing

[Dave Hansen]

On 07/25/2014 09:27 AM, Wilco Dijkstra wrote:
>> On 07/25/2014 08:06 AM, Wilco Dijkstra wrote:
>>> Is there a reason Linux does not do background page clearing like other OSes to reduce this
>>> overhead? It would be a good fit for typical mobile workloads (bursts of high activity
>> followed by
>>> periods of low activity).
>>
>> If the page is being allocated, it is about to be used and be brought in
>> to the CPU's cache.  If we zero it close to this use, we only pay to
>> bring it in to the CPU's cache once.  Or so goes the theory...
> 
> I can see the reasoning for 4KB pages and small allocations (eg. stack),
> but would that ever be true for huge pages?

Probably not, but huge pages aren't allocated and freed enough in any
workload that I know of for this to make a difference for them.

>> I tried a zero-on-free implementation a year or so ago.  It helped some
>> workloads and hurt others.  The gains were not large enough or
>> widespread enough to merit pushing it in to the kernel.
> 
> Was that literally zero-on-free or zero in the background? Was the result
> the same for different page sizes? My guess is that the result will be
> different for huge pages.

Literally zero-on-free for 4k pages only.  I did it inside the
per-cpu-pages lists.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>